很多人第一次用 AI 写代码，会经历同一个循环：
- 一开始惊艳：几句话就能跑起来。
- 接着失望：同一个问题反复改，越改越乱。
- 最后分化：有人把 AI 当玩具，有人把它变成生产力。
我的结论很简单：AI 写代码的上限，不在模型有多强，而在你把它放进什么样的工程系统里。
这篇文章我想分享一套我自己更偏“工程化”的用法：目标是让 AI 从“概率抽卡机”，变成“有护栏、有验收、可迭代”的交付流水线。
1. 先把心态摆正：LLM 更像补全器，不是推理器
LLM 的核心机制是根据上下文预测下一个 token，它可以表现得很像“在推理”，但多数时候它是在做高概率补全。
所以你会看到这些现象：
- 同一段需求，换个表述，结果差很多。
- 它能写出看起来很对的代码，但细节一跑就爆。
- 它会非常自信地胡说八道（尤其在上下文不足时）。
这不是“你不会提问”，而是模型的工作方式决定了：默认输出并不稳定。
因此，AI 对使用者的提升是“乘法关系”：
- 你本来就能做正确的架构权衡、能兜底、能验收 → AI 放大你的产能。
- 你对业务/工程不熟，无法判断对错 → AI 放大混乱。
把这点想清楚，后面的策略才有意义。
2. 最关键的变量：高质量上下文 + 明确验收
AI 不是“知道一切”，它只是在你给的上下文里做局部最优补全。
所以真正的秘诀不是“问得更花”，而是：
- 给它足够的上下文（业务边界、约束、现有实现、依赖关系）。
- 把验收标准写出来（什么算完成，什么算失败）。
一句很俗但很真诚的话：
你不写验收标准，AI 就会自己发明一个。
通常它发明出来的标准就是：代码看起来像那么回事。
3. 推荐工作流：先 Plan 再 Execute（不要一上来就让它开写）
我自己基本固定成一个节奏：
- 先让 AI 输出计划（Plan）
- 拆成原子任务（涉及哪些文件/函数）
- 明确输入输出（I/O）
- 写验收标准（测试点/接口契约/边界条件）
我确认计划没问题（特别是边界与 trade-off）
再让 AI 按计划逐步执行（Execute）
- 每次只改一小段
- 改完立刻跑测试 / lint / 类型检查
- 失败就回滚或修复，不让错误扩散
这样做的好处是：你把“探索空间”先收敛了，AI 的输出会稳定很多。
4. 让项目“自描述”：把隐性知识显性化
AI 最大的坑之一是：老项目有大量隐性约束。
比如：
- 改了 A 字段要同步更新 B 表。
- 某个字段必须先校验库存才能写。
- 某段逻辑历史上踩过坑，所以才这么写（但代码里没有原因）。
人类靠经验记住了，AI 看不到，就会在重构时把这些约束全抹掉。
我的做法是让项目尽量“自描述”，把隐性知识写成 AI 能读懂的东西。
4.1 全局规范文档（一个就够，别写太多）
常见文件名例如：AGENTS.md / CLAUDE.md / project.md / .cursorrules。
内容建议包含：
- 项目概览：业务目标、核心价值、目标用户
- 技术栈：语言/框架/版本（非常重要，别让 AI 用错语法）
- 架构约定：模块划分、依赖关系、目录结构
- 关键约束：API 路由前缀、错误处理、认证机制、命名规范
- 开发规范：lint/formatter、git 提交规范、日志格式、测试要求
原则：够用就行，写多了反而过期。
4.2 分形文档（懒加载上下文）
如果你用的 AI 工具会在搜索/进入目录时自动读取目录下的说明文件，那就可以利用它：
- 每个业务模块目录放一个
CLAUDE.md - 里面只写这几件事：
- 这个模块负责什么/不负责什么（边界）
- 关键类/关键入口
- 业务规则与约束
- 常见修改场景（新增/改动怎么做）
这比“全局大文档”靠谱，因为模块文档离代码更近，更不容易过期。
4.3 源码头部三行注释：INPUT / OUTPUT / POS
这是我非常推荐的一个小技巧：
- INPUT：依赖什么（外部服务/表/配置/上游调用）
- OUTPUT：提供什么（对外接口/返回结构/副作用）
- POS：在系统中的地位（模块定位）
因为 AI 读文件通常是从头开始读，你把语义放在第一屏，它就不容易误解。
5. 控制上下文：一个 session 只做一件事
AI 写代码质量下降，很多时候不是它“变笨了”，而是：
- 上下文太长，关键约束被挤掉
- 历史对话里混了太多目标，导致它目标漂移
所以我会刻意：
- 一个会话只做一个功能/一个任务
- 做完就开新会话
- 旧会话里重要结论要沉淀到文档/规则里，而不是靠“记得住”
有点像写代码别靠 IDE 缓存：重要信息应该落盘。
6. 安全第一：隔离环境 + 最小权限
AI 的误操作不是“会不会发生”，而是“什么时候发生”。
建议：
- 能在 sandbox / 测试库跑的，不要在生产库跑
- 给 AI 的权限越小越好（尤其是删除、迁移、批量脚本）
- 任何破坏性操作都需要人工二次确认
这不是不信任 AI，这是对系统负责。
7. 用测试/验收 harness 替代人肉 Code Review
AI 可以在很短时间生成海量代码，人类很难像以前一样逐行 review。
所以要把质量控制从“人工读代码”迁移到“自动验收”：
- 清晰的验收标准（接口契约、边界条件、性能指标）
- 完整的测试体系（单测/集成测试/回归测试）
- 尽可能让 AI 自己写测试，并让测试约束它
最理想的状态是：
让 AI 在 harness 里奔跑，而不是在生产里裸奔。
8. 把常用套路沉淀成 Skill，把探索交给子智能体
当你发现自己反复对 AI 说同样的规则、同样的纠错、同样的命令，其实就说明：这应该被沉淀。
- 常用提示词、规则、纠错流程 → 沉淀成 Skill（复用）
- 大范围搜索、读文档、对比方案 → 交给子智能体（省主上下文）
主会话尽量只保留“决策所需的信息”，不背无关的噪音。
9. 记录决策原因（ADR）：给未来的你和 AI 一个锚点
很多“看起来很丑”的实现，其实是历史约束下的最优解。
如果不记录原因，AI 或者后来的同事在重构时很容易把它“优化掉”，然后踩回老坑。
所以我建议：
- 关键架构决策写 ADR
- 写清楚：背景、可选方案、最终选择、取舍、风险、回滚策略
这类信息属于高价值上下文，能显著减少后续抽卡。
10. 最后总结：把 AI 当“高速实习生”，不是“全自动交付机器”
我现在更愿意把 AI 理解成：
- 产能极高
- 速度极快
- 但默认不可靠
你要做的是提供：
- 上下文（让它知道现在是什么系统）
- 约束（让它别乱来）
- 验收（让它知道什么叫完成）
- 反馈闭环（错了就沉淀成规则/文档/测试）
当这些工程条件具备以后，AI 的价值会非常稳定：它不只是写代码，而是帮你批量生成实现、批量探索方案、批量补齐测试、批量做迁移与重构的脏活累活。
——
如果你也有自己的 AI Coding 流程/踩坑经验，欢迎交流。我更感兴趣的是：哪些护栏真的能让团队长期稳定提效，而不是短期爽一把。