AI时代的DSL-Spec与Harness Engineering实践

导语

大模型极大降低了代码生成的门槛，但“能写代码”并不等于“能构建可维护的系统”。当开发者被动接受AI的输出，缺乏架构约束的代码将迅速演变为难以维护的焦油坑。AI时代的软件研发，正经历从“效率革命”向“效果革命”的范式转移。本文基于TocoAI的工程实践，探讨如何通过“设计时左移”与Harness Engineering，利用DSL-SPEC重塑研发本体，让AI在可控的轨道上释放真正的生产力。

核心问题与挑战

在AI Coding看似繁荣的表象下，真实的工程落地正面临严峻挑战：

• 架构缺失与维护灾难：AI Coding门槛极低，但AI缺乏全局架构知识。被动接受AI输出，会导致系统迅速失控，长期维护成本极高。
• Spec Coding的四大痛点：为了约束AI，我们需要Spec，但编写和维护Spec本身极其困难：
  1. 定义难：需要开发者具备架构知识，而非仅仅充当AI的“提示词搬运工”。
  2. 维护难：业务持续变更导致规约迅速熵增，长期保持Spec的逻辑自洽极具挑战。
  3. 协作难：团队协作中，Spec的合并与同步运作困难。
  4. 验证难：规约层缺乏编译器等硬性物理反馈，Spec极易产生自相矛盾。
• AI的固有局限：AI存在信息不全、懒惰、缺乏大局观和不懂审美等缺陷，无法完全依赖其完成闭环。

方案与实践

面对上述挑战，Harness Engineering提供了一套从规约到代码的系统性解法。

1. 设计时左移与Spec的演进

传统的运行时和编译时纠错成本极高，必须将约束“左移”至设计时。Spec的发展需遵循清晰的演进路径：

• Spec First：在AI动手写代码前，先写详尽的功能规约，明确动机与边界。
• Spec As Source：规约不再是文档，而是系统的唯一信源，代码只是规约的投影。

2. DSL-SPEC：形式化规约与研发本体

自然语言充满歧义，无法作为严谨的信源。必须采用DSL-SPEC作为形式化符号：

• 排除歧义：通过视觉化表达和严格的数据格式，消除自然语言的模糊性。
• 构建研发本体：DSL-SPEC不仅是描述，更是构建系统“本体”的基石，确保业务逻辑的底座自洽。
• 可对应代码：DSL-SPEC能够直接映射到代码结构，为后续生成提供确定性依据。

3. Agent + Programming：Harness的最佳范式

在Harness Engineering中，必须严格区分确定性与非确定性问题的处理边界：

• Agent处理非确定性问题：利用大模型的泛化能力处理需求解析、逻辑补全等模糊任务。
• Programming处理确定性问题：对于具体行为和强一致性逻辑，一行代码胜过千言万语。确定性逻辑必须用编程约束，由建模引擎生成80%的结构性代码，避免AI的自由发挥引入隐患。

4. Human-In-The-Loop：弥补AI的局限

全自动化并非当前的最优解，半自动化的Human-In-The-Loop更具工程合理性。在结构、状态（存储）、数据流转等关键节点，必须引入人工干预，以此修正AI的信息不全与大局观缺失，确保系统符合业务审美与核心诉求。

5. 从存储驱动到建模驱动

传统的“DB+流程”存储驱动模式是烟囱式构建系统的根源。在AI时代，必须向建模驱动（本体论）演进：

• 业务即模型，逻辑彻底解耦。
• 决策驱动的数据模型优于流程驱动的数据模型，从底层保证系统的正确性、一致性和因果关系。

6. 落地实践：TocoAI与医疗HIS系统

TocoAI平台通过降低Spec Coding门槛、提高Harness能力并提供长期维护方案，将上述理念工具化。在某大型信创HIS系统实践中（120+核心模块，200+业务流程，800+页面），采用TocoAI后，仅需30人团队（传统开发需数百人），以1/10的人力实现了300%+的提效，充分验证了Harness Engineering的落地价值。

原则/方法论沉淀

在AI时代的工程实践中，以下原则应成为团队的共识：

1. 形式化符号优于自然语言：排除歧义是构建可靠系统的基础，DSL优于Doc。
2. 确定性逻辑必须用编程约束：一行代码胜过千言万语，不要让AI猜测确定性规则。
3. Spec必须可管理、可检查：规约应与代码同步演进，而非静态的死文档。
4. 决策驱动优于流程驱动：数据模型需保证正确性、一致性和因果关系，拒绝流程硬编码。

总结与行动建议

软件研发正走向“效果革命”，去UI化、去职能化、小团队主流化是不可逆转的趋势，而代码重构将演变为类似GC的自动化过程。面对这一变局，工程团队应立即行动：

• 停止无约束的AI Coding：将Spec First纳入开发流程，强制在设计时明确意图。
• 引入DSL-SPEC：在核心业务域尝试形式化规约，建立业务本体，摆脱自然语言的歧义。
• 重塑人机分工：让AI处理泛化与探索，让Programming处理确定与约束，让人把控结构与状态。

开放问题与延伸方向

1. DSL-SPEC的具体语法和语义规则是怎样的，它如何保证与底层业务代码的双向同步而不产生漂移？（关联DSL-SPEC的工程落地细节）
2. 将Spec提升为唯一信源是否会引入单点故障风险，当DSL-SPEC自身出现逻辑矛盾时，系统如何自愈或降级？（关联Spec As Source的架构风险）
3. 建模驱动取代存储驱动在AI时代有何独特优势，为何说本体论是约束大模型幻觉的最优解？（关联本体论与AI局限性的制衡）
4. 强制开发者从AI Coding的“低门槛”退回Spec Coding的“高门槛”，是否会引起研发团队的隐性抵触与学习曲线灾难？（关联团队转型与推广策略）
5. 既然重构将演变为类似GC的自动化过程，那么DSL-SPEC能否作为跨语言、跨架构的中间表示层，实现业务逻辑的无损迁移？（关联技术远景与架构演进）
6. 在医疗HIS案例中，1/10人力提效300%的基准线是如何界定的，这期间DSL-SPEC的编写与维护成本占总工时的比例是多少？（关联提效数据的真实成本结构）
7. Agent处理非确定性与Programming处理确定性的边界如何划定，当Agent在运行时频繁越界调用Programming逻辑时，Harness机制如何防止系统崩溃？（关联Agent与代码的边界控制）
8. 面对大型遗留系统，向DSL-SPEC与Harness范式迁移的破冰步骤是什么，应优先从哪些模块切入以验证ROI？（关联存量系统的改造路径）
9. 能否利用大模型自身的代码理解能力，从存量代码库中逆向生成DSL-SPEC，从而实现“Spec As Source”的冷启动？（关联存量资产盘活的可行性）
10. Human-In-The-Loop在结构、状态等关键节点介入，这种半自动化模式为何比全自动化Agent更具工程落地合理性？（关联人机协同的工程哲学）