AI 编程的"铁律"：从工具到工作流的工程实践
工具用好了，代码还是会乱。纪律不是束缚，是让 AI 从"能干活"变成"干好活"。
前言
过去几个月，AI 编程工具的普及速度超出了所有人的预期。Claude Code、Cursor、通义灵码、Qoder——每个工具都在承诺同一件事：你描述需求，AI 写代码。这确实是革命性的，但革命之后呢？
大量团队卡在了一个共同的瓶颈上：编码快了，但交付没快多少。AI 两分钟写完一个功能，人类花二十分钟审查。产出速度远超审查速度，代码越堆越多，质量却越来越难保证。
这里有一个容易被忽略的事实：问题不在工具，在纪律。当编码成本趋近于零，没有纪律的团队会被 AI 产出的速度淹死。这篇文章不讲工具怎么用——那些已经有很多人在写了。我想讲的是：工具用好之后，需要补的工程纪律是什么。
一、纪律从思考前置开始
Karpathy 提过一个概念叫 Think Before Coding。听起来像是废话——写代码之前不都应该先想清楚吗？但在 AI 编程的语境下，这件事比想象中重要得多。
我在一个实际的 Claude Code 工作流中发现，最有价值的配置不是告诉 AI "怎么写代码"，而是四条规则：
第一条：思考前置。 让模型从原始需求、真实目标、客观约束和潜在风险出发进行分析。如果目标不清晰，先停下来讨论。如果路径不是最短、最简单、最稳妥的，直接指出。如果用户把表面症状当成核心问题，继续追问。这一段配置是最值钱的——它把模型从"执行者"提升到"顾问"，避免无脑跑完一个错误的方向。
第二条：Linus 人格。 让模型按 Linus Torvalds 的视角审视代码——简洁、零特殊情况、敢于拒绝烂设计。这是"个性化加强"，把抽象的规则换成一个有审美、敢拒绝的判断者。AI 默认太"礼貌"了，它需要一点"好品味"的锋利感。
第三条：可验证目标。 对应 Goal-Driven Execution。每个任务必须有清晰的验收标准，不是"大概实现了功能"，而是"这个接口在并发 1000 时延迟不超过 50ms，失败率低于 0.1%"。没有可验证目标的任务，AI 会自行定义"完成"——而它的定义往往和人类的不一样。
第四条：工具链集成。 把规则落到工具链的接口，而不是停留在对话里。规则如果不能被机器检查，就等于没写。
这四条规则和我在"深水区"文章里提到的"约束前置"是一脉相承的。只不过那里讲的是流程，这里讲的是每个 AI 交互瞬间的纪律。
Claude Code 和 Codex CLI 最近在 goal 模式上的分歧，恰好说明了思考前置的重要性。Claude Code 用轻量级独立评估器做会话级目标判定，Codex CLI 用 SQLite 状态机做持久化自主执行。两种方式各有优劣，但它们的共同点是：都需要在动手之前明确"目标是什么"。没有目标定义的自主执行，跑得越快偏得越远。
二、把约束变成可执行的规则
思考前置只是第一步。更深一层的纪律是：把约束变成机器可执行、可验证的规则。
Superpowers 是一个把 AI 编程从"凭感觉"变成"工程化"的典型案例。它的核心做法有三条：
子智能体隔离上下文。 每个任务用独立的子智能体执行，主会话只做"调度"。为什么要这样？因为 AI 编程最容易出的问题是上下文炸裂——一个 session 里塞了太多不相关的信息，模型开始混淆不同任务的约束和状态。子智能体隔离就像给每个任务一个独立的工作台，互不干扰。
TDD 是默认而不是可选。 红-绿-重构成为铁律，杜绝"事后补测试"。在 AI 编程中，测试不仅是质量保证，更是"AI 理解了对不对"的即时反馈。没有测试的 AI 产出，就像没有编译检查的代码——看起来没问题，跑起来全崩溃。
设计、计划、代码三者强一致。 设计文档、实施计划、代码 commit 互相引用、可追溯。这意味着 AI 生成的每一行代码都能回溯到设计文档中的某个需求，每一个 commit 都能关联到计划中的某个任务。不是"写了什么就提交什么"，而是"按计划写、按设计验、按约束审"。
这和"深水区"里"把默契变成规则"的逻辑完全一致。但在 Superpowers 这里，规则不是写在文档里让人看的——它是嵌在工作流里让机器执行的。文档写得再漂亮，执行时没人逐条核对，等于没写。
三、从工具到服务
如果说 Superpowers 解决的是单任务的纪律问题，那么 QoderWake 解决的是整个 AI 编程生态的系统化问题。
QoderWake 在 QoderCLI 之上做了 9 大工程模块，把一个"命令行工具"升级为一个"AI 数字员工平台"。这不是简单的功能叠加，而是 AI 编程从个人工具走向组织服务的必经之路。
Daemon 与生命周期管理。 把命令行工具升级为系统服务，标准的 PID/Port/Lock 文件加上心跳管理。AI 编程不再是一次性的交互式对话，而是可以 7×24 持续运行的服务。
Waker 数字员工系统。 每位 Waker 有独立的身份卡——PERSONA.md、TOOLS.md、WORK_STYLES.md——定义了它的角色、能力和工作方式。测试员工 Lily 被自动挂载 6 个内置技能：浏览器操作、变更日志管理、竞品分析、PRD 生成、需求池管理、用户反馈分析。这是从"AI 写代码"到"AI 做工作"的质变。
Trigger 触发器子系统。 QoderCLI 等你敲键盘，QoderWake 让 AI 主动响应外部事件。定时任务、IM 消息、工单、Webhook——AI 不再被动等待，而是主动感知和响应。
Memory 运维。 不是日志记录（写完就忘），而是让记忆成为系统自我进化的载体。失败实验的记忆会在未来阻止相似方向的重复探索，成功实验的记忆会鼓励在此基础上的进一步组合。
安全守卫。 工具调用受 Auth、Policy、Sandbox 约束。能读的不让写，能查个人数据的不让查全量数据。即使 AI 输出了危险动作，执行环境也把影响范围限制住。
从工具到服务的跃迁，意味着 AI 编程不再是个人效率问题，而是组织能力和治理问题。
四、流式输出与上下文压缩——来自 Claude Code 内部机制的启示
理解 AI 编程工具的内部机制，有助于我们更好地使用它。通过分析 Claude Code 的 LLM 日志，可以发现一些非常有价值的工程启示。
工具注册机制。 Claude Code 通过 system prompt 告诉模型有哪些工具可用。这些工具的定义方式——包括工具名称、参数 schema、执行方式——直接影响模型调用的准确率。工具定义不清晰，模型就会"幻觉"出不存在的 API。
上下文压缩与任务连贯性。 随着对话推进，上下文不断增长。Claude Code 的压缩策略不是简单的截断，而是结构化提取——保留语义骨架，摘要压缩核心结论，在紧急情况下截断参考信息但保留约束清单。这个机制告诉我们：上下文管理不是"窗口越大越好"，而是"按需加载、分级压缩"。
流式输出中的并行工具使用。 Claude Code 在流式输出的过程中可以并行地使用多个工具，而不是等一个工具执行完再调下一个。这需要精巧的多指令分割和 JSON 格式完整性保证——在流式输出中完美分割多个指令，保证每个 JSON 结构完整不破裂。
System Prompt 的内容。 Claude Code 的系统提示词包含了角色定义、工具列表、行为约束、安全规则、输出格式等大量信息。这些不是装饰性的——它们直接塑造了模型的每一次输出。理解 system prompt 的内容，就能理解为什么某些配置方式有效、某些无效。
Session 连续性。 Claude Code 如何连续传递会话信息——即使上下文被压缩，关键的任务目标和约束也不会丢失。这是通过外部的状态管理实现的，而不是依赖模型自己的"记忆力"。
这些内部机制揭示了一个事实：AI 编程工具不是魔法，它是一套精密的工程系统。理解它的机制，才能更好地驾驭它。
五、四层 Harness——把概率模型放进生产系统
写到这一步，你可能已经注意到一个模式：所有这些纪律——思考前置、约束可执行、工具服务化、上下文管理——最终都指向同一个概念：Harness。
Harness 是把概率模型放进生产系统时自然生长出来的工程架构。它始终围绕四件事：
连接。 模型的输入和输出都是 token，但生产环境不止是 token。数据库里有记录，文件系统里有路径，浏览器里有页面状态。连接层解决的是模型如何与其他数字资产、其他 Agent 以及物理环境通讯。Tool Calling、MCP、A2A，本质上都是这种通讯关系的不同协议实现。
编排。 短任务里，模型的一次回答、一次工具调用，和用户期待的结果之间距离很近，编排问题不明显。但让 Agent 修一个复杂 bug，它要读代码、定位问题、修改实现、运行测试、根据失败日志继续修——任务时间线无法只靠模型自己维持。编排层要做的，就是把这部分原本依赖人持续维持的过程控制，外化成系统结构。
效能。 一个足够强的大模型加上一个非常耐心且懂业务的人类，理论上可以解决所有问题。但能量消耗太大了。效能层的核心原则是：用确定性的复用，替代重复的人类劳动和重复的 GPU 推理。上下文管理减少重复解释，Memory/RAG 减少人工找资料，缓存减少重复计算，模型路由减少不必要的大模型调用。能用 CPU 上的确定性执行解决的，就不应该每次都让 GPU 上的大模型重新推理。
安全。 当 Agent 开始自主地处理企业数据、执行代码、调用内部系统时，安全显得更加重要。输入侧防注入，输出侧结构化约束，执行侧权限和沙箱，高风险动作人在回路，全链路审计。安全层解决的问题是：当模型行为不可完全预测时，系统如何保证权限、数据、动作和责任边界仍然是确定的。
四层之间存在天然张力：效能追求复用，安全要求隔离；编排追求自主推进，安全要求关键节点停下来等人确认。好的 Harness 设计不止是让四层各自最优，而是在张力中找到适合具体场景的平衡。
关于"把概率模型放进生产系统"这个话题，我会在另一篇文章中专门展开——从连接的具体实现、安全四层防线的详细设计，到 15 款 Agent 模型的安全实测对比。那篇文章会从更技术化的角度，完整呈现生产级 AI 系统的全貌。
结语
AI 编程工具的革命性不在于它让编码变快了——而在于它暴露了一个一直被掩盖的事实：软件工程的基本功，之前都是被人兜底兜掉的。
需求模糊，人靠经验补。上下文丢失，人靠记忆补。约束没说清，人靠默契补。代码有 bug，人靠测试补。当 AI 进入流程之后，这些成本全部暴露，而且回不去。
纪律不是束缚，是让 AI 从"能干活"变成"干好活"。思考前置、约束可执行、工具服务化、上下文管理、Harness 四层架构——这些不是 AI 时代的新发明，是软件工程一直需要、但之前被人的灵活性掩盖了的基本功。
AI 把这些基本功显式化了。不是 AI 要求你这么做，是 AI 让你没法再糊弄了。