工作流：让 AI 能查、能做、能被纠正

本页整理文档、上下文、调试工具与 review 的使用方式。这些是特定实践里的经验，不是通用最优流程。

文档保存原因，也提供入口

有用的文档应帮助后来的人或模型知道去哪里找信息，以及为什么采取这个设计、为什么放弃另一个方案。

当上下文窗口有限时，可检索的文档和阶段产物，比寄希望于聊天记录里一直记得所有细节更稳妥。记录并不越多越好；重要的是需要的信息能否在合适的时候被读到。

规则要在需要它的地方被找到

在 2025 年的具体尝试中，他观察到：把操作规范放在文档某处还不够，相关操作入口也需要明确指向那份规范。

可以从中归纳一个工作原则：减少模型“应该知道去哪找”的猜测。具体措辞对某个模型是否有效，应通过实际结果验证，不能把一段 prompt 当成永久有效的秘诀。

给模型可用的工程工具

构建、测试、调试器和日志，不只是人类工程师的配套设施。模型需要真正能启动它们、读到结果，并据此迭代。

2026 年的实践描述里，详细文档索引和 debugger skill 帮助模型完成了单靠猜测更难解决的问题。但这些工具也没有消除所有能力边界。

review 要有独立视角

在一次 agent team 漏掉 bug 的讨论中，他强调多家模型的视角，并提到在阶段之间清理 context，再把原始要求交给 reviewer。

可迁移的重点是降低执行过程造成的先入之见。不能仅凭同一个模型重复检查的次数，就宣称得到了多份独立意见。

这也不等于同一个模型所有复查都没用。独立性、上下文质量和实际抓错效果，需要分别看。

执行之前先暴露歧义

到 2026 年 10 月，他描述的一项固定做法，是先让模型检查任务可行性和表达歧义。尽早修正需求理解，可以减少后续实现里的绕路和过度工程化。

用这页改进自己的流程

从一个真实失败开始：模型缺了哪份资料，卡在哪个工具，或者 reviewer 沿用了哪个错误前提？只针对这个断点补流程，再用下一次结果判断是否有用。