这篇文章 《Good context leads to good code》是一篇技术团队实地调查式的经验分享，核心观点可以这样概括（原文是英文技术博客：https://blog.stockapp.com/good-context-good-code/）：
“Good code is a side effect of good context.”好的代码是优质上下文的自然产物。
(StockApp Engineering)
🔍 他们在做什么？
2025 年 1 月，StockApp 从零开始搭建了一个工程团队。核心决定只有一个：不写传统代码，而是让 AI 写，人来管理上下文。他们叫这件事"AI 原生开发"。意思是：开发流程从一开始就围绕 AI 设计，而不是事后再塞一个 AI 工具进去。
数据是什么
具体依据：13 周内交付 1098 个 PR，平均每人每周 10.6 个。行业标准，约为每人每周 1 个。但他们自己也加了一句：他们处于项目"构建阶段"，这本身就是最快的阶段。行业标准的数据混了"构建 + 维护"两个阶段。
核心逻辑是什么
他们提出一句话：
好的代码，是好的上下文的副产品。
意思是：AI 写的代码好不好，不取决于模型本身多强，而取决于你给了它多少准确的、结构化的信息。
打个比方。如果你是新入职的员工，公司给你一个清晰的项目文档、架构说明、过去的决策记录，你上手的速度远比什么都没有要快。AI 的逻辑如出一辙。
他们具体怎么做的
第一，所有东西放一个仓库里。
代码、文档、设计说明、规范都在同一个地方。不是为了好看，是为了让 AI 能拿到它需要的信息。
传统团队把文档放一边、代码放一边。AI 看不到那些文档，就会猜。猜错，就返工。
第二，从上到下分层开发。
不是直接把需求丢给 AI。流程是：人写高层设计 → AI 起草细化方案 → 人审核 → AI 写代码 → 人再审。
每一步都有人参与。AI 不是替代人，是在每个环节和人交接上下文。
第三，多个 AI 交叉审查。
他们用了一个叫 Zen MCP 服务器的东西，让 Claude 写好的代码，拿去让 Gemini、o3 也看一遍。
举个例子：同一个身份验证方案，Gemini 推荐一种做法，o3 推荐另一种，理由各不一样。最后人来拍板。
第四，测试是护栏，不是事后补救。
因为 AI 写代码容易"局部优化，全局崩溃"——它的上下文窗口有限，看不到全局。测试是防止这种事的关键机制。
🧠 不是更聪明的 AI 让代码更好，而是有“高质量上下文 + 系统化协作流程”让 AI 产生更可靠的输出。
📈 真正值得追问的是什么
团队实际测量显示：
这篇文章写得很坦诚，值得一提的是，他们没有掩饰风险。他们承认：
AI 代理曾多次"炸掉"他们的开发数据库。
他们说，使用 AI 的时候，工程师必须"全神贯注"。这种方式对软件工程专业知识的要求，👉不是更低，而是更高。
问题或许不在于 AI 能不能写好代码。而在于：
如果一个团队把大量开发工作交给 AI，那么真正在承担风险的，是谁？
📌 还有一个没说出口的前提
这套流程能跑，有一个条件：团队里的人必须足够懂技术。
他们团队来自 Google 等顶级工程组织。他们知道"好的代码是什么样的"，才能判断 AI 写出来的东西是不是对的。
如果换成一个经验不足的团队，用同样的流程，结果会是什么？
这个问题，原文没有回答。
他们说，决定效率的，不是你用的哪个模型。而是你的项目有没有被写清楚。
这句话本身没问题。
真正的问题是：写清楚，需要的时间和能力，和写代码本身，哪个更难？
如果你愿意，可以自己想想。
