还是想问一下大家是怎么 AI 编程的

[CEBBCAT]

（请不要不读正文就‘高谈阔论’，多谢！）

新进入一个项目组，组里氛围很好，大家都朝气蓬勃的，但是好像没有 landing 过程，说起来也加入组里 2 月了，做了一些功能改造、错误率优化，但现在如果问我其中两个主要功能的实现逻辑，我只能说个 50 字的大概抽象，对于时序图、系统拆分、API 和 MQ 分别负责什么，我回答不上来

但我们是希望能够提高工程化，建立起统一的响应结构、错误码、代码库结构、系统分拆、可观测性的。

但在这样盲人摸象的情况下，不仅谈不上清晰的需求迭代，而且规范代码编写、可观测性改造也无从下手

所以想问一下社区里的大家，现在是怎么 AI 编程的

---
自我思考：vibe coding 被提出也有 1-2 年了，新小组 100%代码都是 AI 生成的，成员对代码库心智地图有些模糊，业界有 ADR 、Spec 这样的实践，也有说全自动 AI 完成，AI 编写+AI 审核+AI 验收的办法。

但是我设想的方式：对一个仓库，首先明确业务需求，其次使用时序图、流程图进行抽象层面、分拆到模块的设计。此为心智地图+系统设计

实践层面约定好统一的 JSON 响应结构、project layout 、注册型错误码 module ，日志和 tracing 标准，这样才可以有效控制仓库复杂度，让 AI 在轨道里面工作，去填充那些被方案评审确定下来的 OpneAPI 、DB DDL 之间的空间，这样才能持续化发展？

[athershu]

你设想的方向我觉得是对的，补几条我们组实际在用的：

1. 约定先落成仓库里的文件，再谈让 AI 遵守。响应结构、错误码、目录布局、日志字段这些，写成一份给 AI 读的规则文件放在仓库根目录，AI 每次开工先读；能写成检查的（ lint 、架构测试、错误码注册校验）尽量写成检查，规则文件只管写不成检查的部分。

2. 心智地图可以让 AI 帮你补。你现在对两个主要功能说不清，可以先让 AI 读代码，按功能产出时序图和模块职责说明，你对着代码核一遍，改对了存进仓库的文档目录。这既是你的 landing ，也是后面所有任务的上下文。

3. review 发现一个坑就补一条规则。比如「这个目录是生成的不许手改」「这个接口必须幂等」，当场写进去，之后谁派的任务都会带上。规则是慢慢长出来的，不是一次设计完的。

4. 任务粒度小一点，一个任务一个分支，交付带一段说明（改了什么、怎么验证的、哪里不确定）。100% AI 生成的代码库，最怕一次改一大片、没人说得清为什么。

全自动「 AI 写 + AI 审 + AI 验收」我们没敢这么做，至少每块代码要有一个人看过它的结构和关键路径，不然就会出现你现在这种「代码都在，但没人脑子里有地图」的情况。

[CEBBCAT]

@athershu 沉默是我无言的告白……
---
@Livid 帮忙 ban 一楼号+删回复吧？多谢🙏

[frank1256]

额，哪有这么复杂，一般我都是找个以前写好的比较标准的代码，然后就叫 ai 去模仿就行了，让 ai 核心处理的主要是理解需求，代码已经有模板了。只有核心的 sql 会 review ，其他基本不看

[cheng6563]

执行流程就该让代码本身描述，修改变动说明直接让 git 提交信息体现。
需求文档只留原文归档。
只留全局 Spec 解释核心框架规定。其他分支框架都按 Skills 按需加载。写一堆只管写不管读的 Spec/ADR 没啥鸟用，只会徒增漂移。
API 文档不留，响应结构不留。直接让 AI 读源码（前提是必须强类型语言）；

[unused]

时序图、流程图是给人看的，不是给 AI 看的，你想看就让它当场根据代码画一个

[jackOff]

项目里至少有一个模板项目，最好是经历实际业务考验的，这种项目拿来开发新项目不管是有没有 ai 都稳定很多