标准的 AI agent 是这样工作的:它接收一个 prompt,加载文档(或者某个第二大脑),在源文件中 grep,并试图从可用数据中拼凑上下文,基于它的最佳猜测生成解决方案。
AITM(AI Task Manager)的工作方式不同。它维护着自己的、持续更新的代码库知识库,并在工作开始之前就把它提供给 agent。
企业级项目的陷阱 在扩展大型项目时,各个部分(模块、源代码、文档)最终都会触及各自的极限。开发速度变慢,你就会掉进一个陷阱:
• AI 收集到的信息不完整、彼此割裂,或者最糟糕的是,完全错误。
• AI 信任错误的数据,而你信任 AI。
• 代码不再与文档相符。
• 即使是写得很好的 prompt,也是在一切正常的幻觉下运作,而现实完全是另一回事。
再加上一点幻觉,最终结果就会远远偏离预期。
AITM 中的知识有 4 个坚实的层次:
- 契约(Contracts)
为 AI 链接关键信息的逻辑单元:单元测试、源文件、对其他契约的引用以及文档链接。
详见 Business Logic & Contracts 文档。
- DOM 元素
每个 UI 元素都带有自己的 AITM 标签,与业务逻辑和行为逻辑相关联。借助 AITM Dev Tools,可以把这些元素直接插入 prompt。AI 精确地知道它正在修改哪个元素,以及该元素会触发哪些事件。
详见 DOM Explorer 文档。
- 行为(Behaviour)
定义面向用户的功能:用户可以执行哪些操作以及什么会阻止这些操作(例如,点击此按钮会触发校验,然后调用保存函数)。根据需要,它的范围从抽象描述到对函数、类或文件的直接引用。
- 业务逻辑(Business Logic)
那些原本只存在于开发者脑子里的规则和依赖。
AITM 如何坚持事实并解决冲突 在 AITM 中,你创建一个 Task(定义软件应该做什么)。系统随后生成代码、文档、契约和测试。
当信息发生冲突时会怎样?
用户需求始终拥有最高优先级;
文档、契约和最终代码会对照任务进行交叉检查;
如果出现不一致(例如某项需求与系统架构冲突),AITM 会自动记录一个 Bug。
最终,人类仍然是最终决策的唯一权威。AI 会指出冲突,但由人来判断什么是正确的。
个人经验:一行代码都不手写地构建 我在 AITM 内部构建 AITM 本身。它 100% 由 AI 编写。作为开发者,我没有手动碰过代码。我的角色纯粹是定义架构、设计模式和运行规则。
得益于 AI,我可以设计出更加抽象和复杂的结构,它们既严格分离,又深度关联。
关键启示:对于 AI 编写的代码,你需要发明新的架构和模式——对 AI 来说高度可读,即使在人类看来可能显得复杂。有了 AI,你不再受技术边界的限制,只受限于设计和管理架构的能力。
我的不同做法与下一步 我在之前的文章中讲述的内容,同样适用于大多数 AI 编排器。从这里开始,我们才开始与众不同。
在接下来的文章中,我将逐一剖析 AITM 的具体差异——解释我们有何不同、为什么选择这条路,以及它带来了哪些优势。
如今,AITM 已超过 500,000 行代码,即便在这个规模下,我作为一名独立开发者也能管理整个流程。结果明显更好,而且与依赖松散连接的 agent 和插件的现成方案不同,这里没有任何东西会失控。
