来源：Shape Up（Ryan Singer，Basecamp 团队的项目管理方法论）

传统项目管理的做法是"先估计要多久，再安排时间"。Shape Up 反过来：先固定时间预算（他们叫 appetite，即"胃口"），然后在预算内决定做什么、不做什么。时间预算约束计划，而不是计划反过来要求更多时间。

在 AI 编程中，这条原则对应的是一个常见错误：给 AI 一个开放式的任务（"重构这个模块"），不设边界。结果是 AI 无限展开，重构到一半发现需要改接口，改接口又牵连其他模块，最后 context window 溢出，前面的改动开始丢失。正确的做法是在 prompt 中明确三个边界：时间预算（"这个任务控制在 30 分钟内"）、范围边界（"只改这个函数，不碰其他文件"）和排除项（"不要改测试文件，不要改配置"）。边界越清晰，AI 的输出越可控。

来源：程序员修炼之道（Andrew Hunt & David Thomas）

追踪弹（tracer bullet）的思路是：先用一个端到端的简单实现验证整条链路是否通畅，确认无误后再批量执行复杂版本。追踪弹不是原型（prototype），原型用完就扔，追踪弹是最终系统的一部分，只是先以最简形式存在。

在 AI 编程中，批量执行的典型场景是把一个大任务拆成多个 prompt 并行发给多个 AI agent。问题在于：如果第一个 prompt 的假设就是错的（比如依赖的 API 版本不对），后续所有 prompt 的输出都会基于错误的假设，全部白费。正确的做法是先发一个追踪 prompt，只验证最关键的假设（"这个库的 API 是否如文档所说"）。追踪 prompt 通过了，再批量执行剩余的 prompt；追踪 prompt 失败了，说明计划本身需要修改，而不是简单修一下代码就行。

来源：Release It!（Michael Nygard，分布式系统稳定性设计）

Release It! 强调在生产环境中基于真实数据做决策，而不是基于假设。Nygard 的核心观点是：没有被度量的东西，就无法被真正理解。

在 AI 编程中，最常见的违反这条原则的行为是让 AI 直接修改代码，而不先验证现有行为。比如你让 AI "修复这个 bug"，AI 基于阅读代码得出一个判断，然后直接改。但如果它的判断是错的呢？正确的流程是两步：第一步，让 AI 先描述它对现有代码行为的理解，并运行测试验证（"先描述，再动手"）；第二步，确认 AI 的理解正确后，再让它修改。多花这一步验证，可以避免 AI "修复"了一个本来没坏的东西，然后引入新 bug。

来源：Thinking in Systems（Donella Meadows，系统思维入门）

Thinking in Systems 的核心概念之一是杠杆点（leverage point），即系统中投入最小努力就能产生最大改变的位置。在 AI 编程工作流中，有三个层级的杠杆点：计划（最高）、提示词（中间）、代码（最低）。

当 AI 的输出不符合预期时，多数人的反应是在代码层级修补，直接告诉 AI "这里改一下，那里也改一下"。但如果问题出在提示词层级（比如指令有歧义），修代码只是治标；如果问题出在计划层级（比如任务拆分不合理），修提示词也没用。举个例子：AI 连续三次在同一个地方犯错（比如总是忘记处理空值）。在代码层级修三次，不如在提示词里加一句"所有函数参数都要做空值检查"，这是提示词层级的修复。更好的做法是把"需要空值检查"记录到项目的编码规范中，以后所有 prompt 都自动加载这条规范，这是计划层级的修复。

来源：程序员修炼之道

程序员修炼之道提到"量力而行"的理念：不是每行代码都需要同等级别的审查。低风险改动的审查成本低（验证它能跑就行），高风险改动需要高成本的审查（完整代码审查、安全扫描、集成测试）。

在 AI 编程中，这条原则对应的是审查力度的分级。给 AI 一个低风险任务（比如重命名变量、调整格式），只需要验证输出能编译就行。给 AI 一个高风险任务（比如涉及认证逻辑、数据库操作、密钥处理），需要完整审查：检查边界条件、验证安全影响、跑完整测试套件。不分风险等级地对每个 AI 输出做同等详细的审查，要么浪费时间（低风险任务审查过度），要么埋下隐患（高风险任务审查不足）。

来源：丰田 Kata（Mike Rother）

丰田 Kata 是丰田生产系统的核心方法论。它有两个关键概念：改进 Kata（每天做小规模实验，从实验中提取经验，用经验指导下一个实验）和辅导 Kata（把经验传递给其他人）。核心思想是：如果你不刻意地从过去的经验中提取教训并改变行为，历史记录就只是一堆日志，不会自动产生进步。

在 AI 编程中，这意味着你的 AI 工作流需要一个"记忆"机制。不是让 AI 记住所有对话（context window 不允许），而是刻意提取可复用的经验：哪些 prompt 模式效果好、哪些 prompt 模式容易导致错误输出、哪些代码模式 AI 总是处理不好。把这些失败模式（failure pattern）记录下来，下次写 prompt 时直接引用。否则每次新 session 都要从头摸索，重复踩同样的坑。Conducty 用 Obsidian 知识库做这件事，但你用 Org-mode、Markdown 文件、甚至一个简单的文本文件都能实现同样的效果，关键不在于工具，而在于"提取经验并改变行为"这个循环本身。

六条原则来自五本不同的书，但有一个共同模式：它们都不是在告诉你"怎么做"，而是在告诉你"在哪一层思考"。需求预算让你在计划层思考，而不是直接跳到执行。追踪弹让你在验证层思考，而不是假设一切正常。证据先行让你在观察层思考，而不是猜测。杠杆点让你在根因层思考，而不是修补表面。风险分级让你在优先级层思考，而不是平均用力。改进循环让你在学习层思考，而不是重复劳动。

这些原则不需要任何特定工具。你在用 Claude Code、Cursor、Copilot 还是 Codex，不重要。重要的是你的工作流是否建立在这些思维习惯上。