DAG-chat这个项目，从最初构思，到开发，到宣传，前后稀稀拉拉大半年的时间。现在基本算是收尾了，后续也没什么新增功能。最多TypeScript 7.0发布了以后，整个项目升级一下技术栈。这里就简单说下自己当初为什么要搞这个东西，搞的过程中的一些心得。

首先，里面的技术细节，可以看知乎文章：DAG-chat，让AI对话变成思维导图 我在个人博客里面就不赘述了。

说说AI编程

一开始兴起的叫vibe coding，但是只要你想做一些严肃性项目，那么几乎很快就要过渡到SDD（Spec-Driven Development），Spec驱动开发。

其实规范驱动开发没什么新鲜的，完全是新瓶装旧酒。之所以现在拿出来重提，根本原因是，编程这件事的主力逐渐从自然人变成了AI。

在没有AI编程的时候，人类开发一个项目，大概流程是这样的：

  1. 需求评审；
  2. 技术评审，具体内容包括但不限于：架构图，E-R图，逻辑时序图，数据库建表语句，前后端接口定义，配置项，以及测试用例；
  3. 技术评审完了以后，程序员开两个窗口，一个浏览器看技术文档，一个窗口开IDE在里面写代码。

但是当AI编程占比越来越重的时候，摆在面前的问题就是：如何让AI看技术文档？

过去代码在git仓库里面，技术方案在confluence，或者飞书文档/钉钉文档等某个地方。总之在数据上，技术方案和代码是两个孤岛，之间并不联通。那要让AI看到技术方案，最简单的办法就是把技术方案放到代码项目里，让技术方案成为项目代码本身的一部分。因为毫无疑问，AI既然能写代码，那么首先肯定能看到代码。

可是如果把技术方案直接塞到项目里面，那么实际的提升非常有限。为了更好的适配AI，技术方案至少要做以下这么几件事：

  1. 严格markdown化。架构图，E-R图，时序图不能随便截屏弄个.png/.jpg放文档里面了。要使用PlantUML等语法来写；
  2. 文档内容要指令化。什么叫指令化呢？其实很简单。比如说我要开发一个登陆接口: /api/v1/login，该接口要做限流保护，每秒最多300次。这段内容可以使用yaml或者类似的形式，而非自然语言。一个参考的写法就是：
endpoint: /api/v1/login
  qps_limit: 300

这种格式相比于自然语言而言，更加指令化，而不是简单的描述；

  1. 消除歧义，最大程度限制AI自由发挥的空间。还拿刚刚的登陆接口举例：在技术方案里面，我们可能写下这样的东西：如果一个用户连续5次失败，那么要进行冻结。

那么问题来了：冻结什么？冻结账户，还是IP？冻结期间用户是否可以找回密码？这些可能在开发的时候，不会写清楚，而在coding的时候，发现需要细化一下，然后和产品拉一个小会，沟通完毕以后再写。但是这个时候技术文档不见得会更新，这就导致技术方案和实际实现不一致了。但是写给AI看的文档，要写清楚，最大程度消除歧义，并且最好使用严格的伪代码，比如gherkin这种语言。

Feature: 账户级登录安全冻结策略
  作为认证服务
  我希望在连续登录失败达到阈值时冻结账户
  以便防止暴力破解攻击，同时允许用户在冻结期间恢复账户访问

  Background:
    Given 账户 "alice@example.com" 存在于系统中
    And 该账户当前处于正常状态
    And 系统配置的连续失败阈值为 5 次
    And 系统配置的冻结持续时间为 30 分钟

  Scenario: 成功登录后重置失败计数器
    Given 账户 "alice@example.com" 当前连续失败计数为 3
    When 用户以正确密码提交登录请求
    Then 系统返回认证成功响应
    And 该账户的连续失败计数重置为 0

  ...

这种写法可以十分严谨，最大限度避免AI自由发挥。

  1. 建立索引，对技术方案切片，节约输入token。一个项目里面，往往会迭代多个需求，如果不做索引切片，那么技术方案内容会越来越多。那么这些东西如果都丢给LLM的话，会极易撑爆LLM的上下文窗口。所以需要建立索引切片。一般可以按照序号顺序，按照功能先后顺序切片，每个markdown文件里面的metadata把该文档功能点做一个详细说明。可以先让LLM生成一个000_spec_template.md文档，然后后续的功能都按照这个模版来进行。

做好以上4点，可以极大地提升AI读取技术方案的效率和准确度，从而最大限度释放AI编程的潜力。或者干脆更简单点，直接问AI，当前项目的Spec还需要做哪些改进。

SDD说到底和之前人类在开发的时候，是没有区别的，都是先写技术方案，然后再干活。只不过现在技术方案是写给AI看的。

相比之下，之前的vibe coding实际上是干嘛呢？开一个终端窗口，或者IDE里面开一个AI聊天面板，告诉AI，给我实现什么什么。这好比在人类编程时代，程序员想到了一个功能，一不去核对产品细节，二没有设计好技术方案，直接就开始动手来撸。之前的AI能力有限，主要在方法/函数层面辅助编程，这样做其实没什么问题，因为人类在写方法/函数层面的代码的时候，也不需要搞什么技术方案。但是现在随着AI的能力增强，AI逐步地要跨函数、跨文件，在系统架构层面进行设计的时候，就不是三两句话告诉AI干什么就够了，必须要建立清晰严谨的技术方案好让AI看，或者说对AI进行约束。

AI能放大多少？

AI编程基本上可以分为两大类：

  1. 你懂这个事儿要怎么干，使用AI编程是为了提高效率，快点出活儿；
  2. 你不太懂这个事儿要怎么干，比如使用一门新语言，新框架写代码。你使用AI是为了补齐自己的能力短板。

对于第一种情形，在认真做好SDD的前提下，2026年优秀的Coding Agent + 旗舰LLM，基本上可以做到 >= x5的效率放大。比如Claude Code + GLM-5.1，或者Kimi Cli + Kimi 2.6。因为你知道怎么干，那实际上用AI就完全是体力活代劳而已。如果说重复性工作量很大的话，甚至可以达到x10的效率放大，毕竟人的并发和计算机的并发是两码事。工作量越多，AI提效越明显。

对于第二种情形，效率放大取决于需求是否常见，以及功能是否描述清楚。对于不了解的领域，放大倍数不完全保证为正，也有可能以惊人的速度给你带来麻烦。

结合我个人经验，我总结对于不熟悉的领域，使用AI干活要重点搞清楚这么几件事：

  1. 要有扎实的数据结构和算法功底。如果使用的是你不熟悉的语言/框架，那么一定要用自然语言清晰地描述好数据的结构和流转方式。从这一点讲，vibe coding反而将编程这件事回归本质了。毕竟绝大多数人在学习编程的时候都听过：编程 = 数据结构 + 算法。vibe coding的核心恰恰是用自然语言代替代码，来进行编程。如果自然语言说不清楚，那本质上就是数据结构和算法没有想明白。

  2. 对于不熟悉的语言，可以不会写，但是要学会调试。调试的经验实际上是跨语言的，首先二分法定位问题所在的逻辑区间。控制变量法确定问题的输入因素来源。在关键的执行步骤前后，打好断点，记录好帧栈信息。要知道是从什么时候，数据开始出问题的。然后这些东西丢给AI去分析。

  3. 学好入门的术语和概念。一个后端工程师，想做全栈开发，可以不懂React的Hooks，可以不会CSS排版。但是起码得知道什么叫DOM，什么叫前端标签，打开F12，要知道找哪些element。

开源项目的宣传

个人开发者，弄一个项目，其实无外乎这么几个想法：

  1. 锻炼一下自己的编程能力；
  2. 希望能在社区里混一些star；
  3. 项目包装一下，写在简历里可以加分。

开源项目没有宣传是完全不行的，尤其是独立开发者，不像大厂出品自带背书。 DAG-chat到目前为止一共收获了31个star。其中有差不多20个，是熟人点的，朋友、同学、前同事等。除此之外在hacker news, product hunt, X, 知乎，掘金，v2ex等平台上进行了宣传，从这些地方来的star，大概有10个吧。反正我是很满意了。

首先，项目的冷启动，是需要一些人脉的，很多大厂的开源项目，最初的几十甚至上百个star，也有不少是大厂同事的友情star，先起个trend，后面再看社区的技术运营。

DAG-chat目前依旧是一个idea实现，从产品化的角度来说，还是不够，最大的硬伤是没有在线使用的demo。这个要做，需要额外的服务器资源，以及搭建成本。自己暂时还没有精力去搞，后面有时间了再去完善吧。