我在项目里用 AI 参与的不只是“写一次代码”，而是从原型、接口到真联调、问题修复和文档回写的完整链路。真正值钱的方法，不是模型选哪个，而是这套协作怎么定。
这个问题从哪里来
公司在政企空间项目里连续用 AI/Codex 交付了几个功能，结果一度差异很大：有的很顺，有的反复返工。回头看，区别不在“AI 强不强”，而在“我们有没有把协作规则讲清楚”。
第一件：给 AI 足够的项目内锚点
抽象描述最容易让 AI 自己补细节。更稳的做法是塞给它项目里已经存在的事实：
- 参考截图、HTML 原型、现有组件和 DOM 类名；
- 字段名、接口路径、真实请求和响应样例；
- 哪些旧逻辑必须保留、哪些明确不做；
- 当前异常现象、日志或两条可复现的数据。
有了锚点，AI 是在既有工程和业务约束里工作，而不是从零猜一个“通用方案”。
第二件：先对齐不变量，再谈增量
联调平台上做分屏对比、任务状态这类功能时，最有效的开场是一句“哪些不能动”：接口是否改、数据由谁提供、批次用什么字段聚、哪些旧页面不带翻。不变量定死后，后续每轮只补一个明确变化，比如“箭头归属历史图”“缩略图不换行”，而不是反复重贴全量需求。
已确认的规则要沉淀成后续约束，新反馈只改变相关节点，避免在连续迭代里丢早期结论。
第三件：不把 AI 第一版输出当结论
关键原则是：把 AI 的每一轮输出都当成“下一轮可验证的假设”，而不是直接照搬。用测试和真实数据去验证，验证不过就带着证据回来让它改，而不是让它自己圆回去。我习惯的闭环是：明确边界 → 拆分实现 → 小步开发 → 真实验证 → 回写沉淀。
第四件：数值异常先验算，再定位根因
联调目标经纬度时，出现“高度 300、俯仰角 4.51°、算出 3.8 公里、画面看着 400 米”的异常。没有直接换公式，而是先用数值验算排除“公式错”这个假设，才定位到根因是 cameraHeight 是海拔不是离地高度。
数值问题按“验算 → 排除 → 定位根因 → 最小修正 → 真实数据复核”推进，不能用看起来合理的公式替换，去掩盖输入口径的问题。
第五件：匹配、统计类问题先分清三类
分屏对比“有没有配对上”，不要一上来就改前端。先确认请求有没有真正发出去，再用真实样例比字段，最后判断问题属于：状态不同步、视觉布局、接口匹配规则，三者分开查，别跨层误改。
第六件：文档要回写和实现一致，边界与验收由人负责
AI 开发最容易出“代码改了文档没改”。阶段性完成后，让 AI 把设计文档、规则、数据样例同步到最终实现状态。同时想清楚：业务边界、数据口径、现场结论和最终验收，这些仍要由人来拍板，AI 只是降低上下文切换和排障成本。
可复用经验
- 复杂功能先让 AI 熟悉工程（甚至先形成
AGENTS.md），再让它出设计文档和计划。 - 让高质量模型反过来“挑毛病”，检索设计文档里的遗漏和歧义点。
- 明确告诉 AI 硬约束：配置放哪、数据结构、是否允许提交 git、是否允许兼容逻辑。
- 每次功能调整都按“写失败测试 → 跑失败 → 最小修复 → 回归”来约束输出。
- 遇到异常先做根因分析，拒绝猜测式修复。
留给下次
这套方法目前集中在资源有时间、有精力反复打磨的功能上。想把“何时深入、何时点到为止”的边界也沉淀成可通过一个提示快速照做的短清单，让团队成员都能复制。