Tiden：为编码智能体做意图验证的新工具

编码智能体的验证困境

当 Claude Code、Cursor、Codex、Copilot 这类编码智能体越来越深入地参与实际开发时，一个被反复提及的问题浮出水面：我们怎么确认它写的代码，真的是我们想要的东西？

常见的做法是跑测试。但 Tiden 团队在 Product Hunt 上指出了一个关键漏洞——大多数检查都运行在编写代码的同一个会话里，测试与实现共享上下文，于是"测试通过"在很多情况下是构造上就成立的，而非真正独立的验证。换句话说，写代码的智能体顺便把证明自己正确的证据也一起造了出来。

Tiden 想解决的正是这个问题。

编码智能体（Coding Agent） 指能够自主读取代码库、规划修改、编辑文件并运行命令的 AI 系统，典型代表包括 Claude Code、Cursor、Codex 和 GitHub Copilot 的智能体模式。与传统代码补全工具只给出下一行建议不同，编码智能体通常拥有多轮工具调用能力，可以在一次任务中完成跨文件的改动。

这种自主性带来了新的信任问题：智能体不只是提出建议，而是直接落地变更。当它同时负责写实现和写测试时，验证的独立性就被削弱了。开发者在评估这类工具时，除了关注生成质量，也需要关注变更是否可审计、可回滚、可追溯。

Tiden 的核心思路：把意图当作可分支的需求

Tiden 的定位是"意图验证（Intent verification）"。它不把需求当成一份写完就固定的文档，而是把用户的意图保存为像代码一样可以分支和合并的需求记录。每一次代码变更，都会被拿来和这份记录做比对。

这个设计有两个直接后果：

• 需求本身有了版本历史，可以随项目演进而分叉、合并，而不是一份脱离现实的静态文档；
• 验证的不是"代码看起来对不对"，而是"这次改动是否仍然符合当初记录的意图"。

对于经常出现"智能体改着改着就跑偏"的团队来说，这种以意图为锚点的做法，比单纯堆测试用例更贴近真实痛点。

需求的可分支与可合并借用了版本控制系统（如 Git）中分支的隐喻。在 Git 里，代码可以从主线分叉出特性分支，独立演进后再合并回去。Tiden 把同样的模型套用到需求记录上：一份需求可以针对不同场景分叉，验证通过后再合并回主线。

这样做的好处是需求不再是一份写完就过期的静态文档，而是与代码演进同步的活对象。当智能体在某个分支上做出改动时，系统可以把这份改动与该分支对应的意图版本进行比对，从而判断它是否偏离了最初的目标。

不让模型给 diff 打分

Tiden 在验证机制上做了一个值得关注的选择：最终裁决来自在你的环境里运行的测试，而不是让某个模型去给 diff 打分。

这一点和当前不少"用 LLM 评审 LLM"的方案形成对比。让模型评估模型，看起来省事，但会引入新的不透明性——评判者的标准本身难以审计。Tiden 把结论交回给可复现的测试执行，同时保留人来决定什么可以合并。

它还提供了错误追溯：生产环境出现的问题，可以回溯到具体的发布版本。对已经在用智能体做持续交付的团队，这条链路的价值不小。

用 LLM 评审 LLM 是当前常见的验证方案：让一个模型阅读 diff 并给出是否正确的判断。这种做法的问题是评判标准本身不可审计——模型的评分依据隐藏在权重里，无法像测试用例那样被复查和复现。

Tiden 选择把裁决权交还给可复现的测试执行。测试跑在用户自己的环境里，结果可验证、可重复，人工则保留最终合并决策。这一分工把"机器判断"限制在可观测的范围内，避免了验证链条上出现新的黑盒。diff 指两次代码版本之间的差异，是评审流程的基本输入单位。

与现有编码工具的配合方式

Tiden 没有试图取代现有的编码智能体，而是选择并行工作——按官方描述，它可以和 Claude Code、Cursor、Codex 以及 Copilot 一起使用。

这种"旁挂"式的定位降低了采纳门槛：团队不需要放弃已经在用的工具链，只需要在合并环节引入一层意图校验。对于正在评估编码智能体落地风险的技术负责人来说，这是一个相对轻量的切入点。

从 Product Hunt 的数据看，Tiden 获得了 93 票、14 条评论，排名第 6，分类落在软件工程、开发者工具和人工智能交叉地带。这个热度说明"智能体写代码如何验收"确实是当下开发者关心的议题。

意图验证会成为一种基础设施吗

随着编码智能体承担越来越多实际工作，验证层的重要性只会上升。测试覆盖的是"代码有没有按预期运行"，而意图验证试图回答的是"这段代码是不是本来就该存在"。两者并不互相替代。

Tiden 把需求记录变成可分支、可合并、可追溯的对象，这个抽象是否会被更多团队接受，还有待观察。但它至少指出了一个容易被忽视的现实：当写代码的一方同时掌握着验证手段时，独立的外部校验就成了必需品。