一、为什么一谈 AI 工程。大家先想到 Harness

使用者痛点：开发者常感到只能靠临时的防护措施来限制 AI，而缺乏对整体方向的把握，导致项目后期频繁返工。说起来，

当前讨论 AI 辅助开发时最常见的说法是：

• guardrail
• verification
• review
• feedback loop
• agent harness

这套直觉默认了一个前提：

程序正确的方向是已知的。

在此前提下问题自然变成：

• 怎么限制偏离
• 如何尽早暴露失败
• 怎么让 review 更严
• 怎么防止 agent 胡来

这套语言在小任务里是够用的。一个脚本、一页 CRUD、一个局部 bug 修复。大多数时候你已经知道“对的结果长什么样”，剩下的主要是执行和验证问题。说起来，

但大型程序真正困难的地方。往往不是“怎么防止越线”，而是“到底哪条路才是长期正确的结构”。老实说，

二、被抽走的兜底机制

使用者痛点：缺少持续方向感导致代码库漂移。团队只能靠事后手工审查来纠正，却无法预防程序整体偏离目标。

打开任何主流工程方法论——TDD、DDD、Clean Architecture、Agile、Code Review 文化——它们的一等公民评价对象几乎都是状态：

• 评价“这次 PR 对不对”，不评价“过去 N 次 PR 累积出的方向对不对”。
• 评价“当前架构是否清晰”，不评价“架构在演化中是否被持续推向某种稳定形态”。怎么说呢，
• 评价“测试是否覆盖当前行为”。不评价“测试套件本身是否被实现细节腐蚀”。老实说，

传统方法论并非完全没有轨迹意识——重构、技术债务、坏味道、演进式架构、Lehman 软件演化定律都涉及轨迹。但这些概念在程序里的地位是修正机制和诊断词汇,而不是基础对象。一个理论需要不断引入“债务”“脆弱性”“腐蚀”这类否定性概念来追认轨迹问题，恰恰反映它的基础范畴集里没有正面的轨迹对象。

AI 协作把这个兜底机制抽走了。怎么说呢，AI 不是更快的程序员。而是结构上不同的扰动源**：

• 高频：一个 session 可能在几分钟内生成数百行涉及多模块的代码。
• 高幅度：每次生成都可能引入跨边界的结构性变更。
• 无持续方向感：每个 session 独立，没有跨 session 的隐性架构判断。
• 局部高度合理：接口、类型、测试、文档可以同时给出，每一项单独看都能通过检查。

User Pain Point: 即使所有状态层检查均通过程序整体仍会出现不可察觉的漂移，使得后期维护成本爆炸。

三、动力程序语言：把轨迹问题显式化

User Pain Point: 缺乏统一概念导致团队成员在讨论 “收敛” 与 “控制” 时各说各话，难以形成一致行动方案。

在数学物理中，动力程序`指的是状态随时间持续演化且接下来依赖当前状态的程序。我们关心的不只是某一时刻是否正确，而是它在时间中会走出怎样的轨迹.

对应到 AI 大规模开发。这套语言对应四个相互定义的基础对象：

• 状态空间：S 程序在当前约束下所有可能演化到的实现状态集合。
• 吸引子 ： S 长期演化中反复被拉回的稳定结构。
• 轨迹 ： S 每轮生成‑验证‑纠偏后真实留下来的演化方法。
• 控制 ： S 通过局部信号持续影响轨迹的一系列机制。

这里必须明确这方面。这套语言不是换个更优雅说法，而是新本体论的基础语言；话说回来，缺一不可，否则无法完整描述 AI 协作中的收敛问题。

User Pain Point: 团队经常把「长期目标」当成硬性边界。从而误判一次违规即为错误，而忽视了「可容错」与「渐进收敛」之间的关键平衡。

Lorenz 吸引子示例说明：局部轨迹高度复杂且近似混沌，但整体始终被同一几何形态约束。其实，工程里的 attractor 同理。它更像“一组方程定义流形”，而非枚举所有合法点。

• 结构层: 少量高阶不变量，如职责划分、边界约束等主要原则。

五、仓库开始承担程序真相，Harness 因而成为基础设施

User Pain Point: 开发者仍旧习惯于 “一次提交即完成”。导致生成代码与评估过程耦合，从而陷入自我验证循环——错误一次生成，全链路证据同步错误，却难以发现根本问题。

• 生成与验收分离原则：  代码生成快速；验收必须回到 live repo 重新审视；所有权威材料均来源于仓库历史记录.

  ...