使用 AI 编程工具而不丢失架构

从约束出发，而非从自动补全出发

当任务有界时，AI 编程工具表现出色：实现此接口、添加此测试、迁移此调用点。当被要求发明仓库尚未表达的架构时，它们会吃力。先提供不变量——所有权边界、命名约定、错误模型与禁止的捷径。

工程师仍对框定负责。模糊提示会产生看似合理却悄悄重复现有模块或绕过共享工具的代码。

把生成的变更当作架构来审阅

看向语法之外。变更是否尊重模块边界？是否引入新的持久化路径？是否处理授权与失败？大型生成 diff 诱使略读；坚持人类真正能理解的小提交。

当决策昂贵且难逆时，向工具索取替代方案。比较两种方法往往比接受第一稿更有价值。

• 对无法目视验证的行为要求测试
• 添加新助手前先搜索现有助手
• 将密钥与生产数据排除在提示之外
• 优先仓库文档，而非通用框架传说

保护反馈环

类型检查、lint 规则、契约测试与预览环境，使高速生成变得安全。若套件薄弱，AI 只是帮你更快产出未经验证的复杂性。

把节省的部分时间投入更好的夹具、更清晰的模块 README，以及首选模式示例。这些产物同时改善人类与 AI 贡献者。

把品味留在环中

架构是约束下积累的品味。AI 可提议实现；它不能拥有产品的未来。用工具加速已验证的工作，而不是外包关于系统应成为什么的判断。

与 AI 编程工具共赢的团队对边界有纪律。代码更快，因为轨道清晰。