这是一个创建于 86 天前的主题，其中的信息可能已经有所发展或是发生改变。
ai 能力很强，但是如果仓库的代码量越来越大，还继续纯 vibe coding ，大概率你的项目会越来越乱，越来越难以维护和管理
那么为什么人类工程师写代码不会这样？
我自己想了一下我的开发行为，大概是这样的：
- 接到一个需求，理解需求具体是要干什么
- 我的大脑自动 rag 一下，回想起这个需求相关的可复用的代码 kit ，规范是什么，以及存放在哪里，该咋用
- 开始 coding
- 再对照我记忆里的“这种需求的代码在这个项目该怎么写” 的相关规范进行 review 一下
- commit && push
所以为什么 ai 做不到这样？一个是 vibe coding 的人有可能本身就是纯小白零基础，自己也不知道该怎么写代码才是规范的，也有可能是被需求，排期填满的工程师，没有很多空去每次写需求都让 ai 走一遍完整流程（全走完流程的话说不定工程师自己都差不多写完代码了）
all in all ，为了解决这个问题，我们内部仿照人类工程师的开发模式打造了一套给 ai 的工作流，我们会把代码的各种结构规范和开发准则进行沉淀形成文档，把 commit 相关信息也沉淀到文档中，这样每次跟 ai 对话之前，可以用对应的流程只注入它需要的 context ，这样在实际 coding 之前，你得到的就不是一个 预训练过很多预料，coding 能力很强，但是会随机发挥 coding 能力的 agent ，而是一个熟悉你项目最近提交情况，熟悉本次需求开发相关代码该咋写的代码工程师了；
在 coding 结束之后，也会有类似的强行注入 review 相关所需上下文的流程去进行 code review ，防止 coding 过程中因为上下文太多，忘记代码规范是什么；
以及在工作完成之后，会有专门流程检查本次 coding 是否产生或者修改了对应的开发规范，如果有这种情况就会对开发规范进行修改，做到越用越好的效果
我们内部觉得这是一个非常提效的流程，最近可能开源出来, 会有人想用这种东西吗
 | 1 byheaven0912 1 月 27 日 openspec ，superpower ，一大堆这样的项目了 |
 | 2 fmfsaisai OP @byheaven0912 superpower 和 openspec 都不好用...,superpower 还好点, openspec 更是跟没有一样 |
 | 3 hellopz 1 月 27 日 我的最大阻碍是沉淀代码规范，整理出 ctx 才是最大的问题，怎么使用 ctx 无关紧要，我人手工复制粘贴给 AI 递材料都行 |
 | 4 cssTheGreatest 1 月 27 日 我们的实践下来，vibe coding 的痛点在于它和业务需求之间，仍需要一个“翻译”的过程，也就是您说的： “我的大脑自动 rag 一下，回想起这个需求相关的可复用的代码 kit ，规范是什么，以及存放在哪里，该咋用” 例如我是前端，来了一个需求说“订单管理页增加一个新的 CRUD”，我大脑里会去 rag 相应的代码仓库、文件、接口、旧逻辑、影响面，然后再开工。而 agent 在仅阅读代码仓库后，它只会尽量‘猜测’一些相关性，就容易导致改错、做错。 Vide coding 在 “纯写代码”层面我们觉得已经完全 ok ，包括代码规范、合理性、性能、安全等，但还没法代替我们去“思考”该怎么完成业务需求。 我们在 BMAD 和各种 XXX Spec Driven 的试验后，开始尝试建立一个上下文仓库，包括我们之前的需求 PRD 、测试用例和项目文档，希望能让 agent 基于这个上下文能代替“我”的思考 |
5 cc9910 1 月 27 日 感觉还是上下文的问题, 比如项目里,我大概知道那个是关键点,遇到问题也是复用或者修改那个地方, 但是 ai 要么就是全部记住,要么就是写一个超长的引用,然后每次扫一遍,导致它记不住全部,每次都是新的开始 |
 | 6 mxT52CRuqR6o5 1 月 28 日 我目前认为没有长期记忆能力没法从根本解决这个问题，现阶段提高上下文长度需要指数级地增加成本，不可持续，还得需要一些技术突破才行 |
 | 7 bytesfold 1 月 28 日 via iPhone 我已经做好了，从需求到测试 |
 | 8 ludage 1 月 28 日 戳中我的痛点了。我不知道该如何有效的跟 AI 沟通(大任务)，可能是我描述的不好、文档有问题，做出来的东西跟我想象的，差距很大 |
 | 9 jolly336 1 月 28 日 OP 试过 Github 开源的 https://github.com/github/spec-kit 吗？这个是不是就能满足你的要求 |
| 10 fmfsaisai OP 总而言之仓库开源了,项目名字是 Trellis, ai 能力像是爬墙虎一样生命力很强但是会乱爬，我们希望我们的框架能能像一个脚爬架一样让它按照规范前行 原 repo: GitHub - mindfold-ai/Trellis: All-in-one AI framework & toolkit for Claude Code & Cursor 简短版 README: Trellis/README_CN.md at main mindfold-ai/Trellis GitHub 详细理念介绍: Trellis/docs/guide-zh.md at main mindfold-ai/Trellis GitHub (如果你懂 k8s,可以看看这个文档方便理解我们的理念: Trellis/docs/use-k8s-to-know-trellis-zh.md at main mindfold-ai/Trellis GitHub) 走过路过点点 star ~ |
 | 11 xsonglive491 1 月 28 日 相当于每次都要写一个完备的需求文档.各种 spec 工具生成的文档都是一次性的,新的任务无法参考旧有的文档.可能需要的是从测试开始而不是代码开始 |
| 12 fmfsaisai OP @xsonglive491 tdd 在 roadmap 里, 新的任务能参考旧有的 spec 规范啊,这个就是我们的特色, 然后需求文档是 ai 根据你的需求写一版本, 然后人工 review 一下 |
| 13 fmfsaisai OP @cssTheGreatest bmad 我个人感觉太重,太繁琐了点,其它那些 spec-driven 的框架本质是 "prd-driven" , 而我们这个是 coding-spec-driven , 其次,注入的规范会是专门存放的各种 coding 实际规范,会是之前项目沉淀下来,确认百分比准确,可用,正确的东西,比如 “在执行 db 批量操作时,应该用 orm 的 batch 方法,而不是在 for 循环里执行 db insert" 这种明确规范,这些规范就是为了去保证您说的 代码规范、合理性、性能、安全等 case, 避免改错,做错 以及最重要的思考,我们其实也是做了一些优化的,就是 guides 目录,里面会存放让 ai 先思考这次改动需要涉及什么东西的思考指南,比如是否涉及跨层的数据流动? 是否需要新造组件,还是应该直接先去找旧代码复用? 改了这一个地方,其它地方是否需要相关修改? 大概内容会是这样 /*****/.trellis/spec/guides bug-root-cause-thinking-guide.md db-schema-change-thinking-guide.md semantic-change-checklist.md code-reuse-thinking-guide.md index.md spec-flow-template.md cross-layer-thinking-guide.md pre-implementation-checklist.md sync-data-consistency-thinking-guide.md |
| 14 fmfsaisai OP @jolly336 spec-kit 和 openspec 我们都试过,这些本质上是 "prd-driven", 而我们想提高代码质量实际需要的是 "coding-spec-driven" ,有好的,且得适用于你在改的某个深度特化过技术栈的项目的代码规范(其实就是高级工程师脑子里的,知道怎么写出高质量可复用的代码的那些知识,我们将它们沉淀形成文档), 让 ai 了解这些东西才能写出真正高质量的代码 |
| 15 fmfsaisai OP @mxT52CRuqR6o5 如果用我们这套流程的话, 每次结束对话时用 `/trellis:record-session` ，AI 会把会话摘要写入 `.trellis/workspace/{name}/journal-N.md` ，并在 `index.md` 建立索引。下次 `/trellis:start`时，AI 会自动读取最近的 journal 和 git 信息，恢复上下文。(所以理论上直接扒每天的 journal 文件就能当你的工作日报提交了) 比如有一个很复杂的需求,你可以 /start 一次,然后跟它讨论确认需求, 然后创建一个 task,然后就可以 /record-session 直接记录 journal ,然后开一个新的会话窗口, 输入 /start 让 ai 自动了解上次的情况, 然后帮你开始具体实施干活。 我们是用这种思路去规避 ai 没有长期记忆的能力的问题 |
| 16 fmfsaisai OP @cc9910 所以我们做了 journl+sub agent 去解决上下文相关的问题,比如前面提到的 ``` 如果用我们这套流程的话, 每次结束对话时用 `/trellis:record-session` ，AI 会把会话摘要写入 `.trellis/workspace/{name}/journal-N.md` ，并在 `index.md` 建立索引。下次 `/trellis:start`时，AI 会自动读取最近的 journal 和 git 信息，恢复上下文。(所以理论上直接扒每天的 journal 文件就能当你的工作日报提交了) 比如有一个很复杂的需求,你可以 /start 一次,然后跟它讨论确认需求, 然后创建一个 task,然后就可以 /record-session 直接记录 journal ,然后开一个新的会话窗口, 输入 /start 让 ai 自动了解上次的情况, 然后帮你开始具体实施干活。 ``` 1. plan agent 先根据你的当前任务需求,去查找 spec 目录下面存放的高质量代码规范(spec 相关的东西可以看前面几楼我有讲),然后找出这个需求相关的需要遵守的 spec 的某几个具体文档 (比如说要写一个新接口,需要有 接口怎么组织,数据流转的相关规范文档 入口-biz-data , 然后每一层代码的大致结构长啥样; 然后写 db 操作需要获取 db 相关的 spec 文档,里面会写类似 如果有批量操作,应该用 orm 的 batch 方法而不是在 for 循环里写 db insert 这种), 然后找出所有本次需要遵守的规范文件,存放到一个目录里 2. 然后启动 implement agent, 上一步获取的文件的内容会被脚本读取出来注入给这个 agent,然后它就知道代码该怎么写,然后实际去干活 然后实际开发可能会遇到各种问题, 然后修复的过程中就可以把新的,正确的知识沉淀到 spec 下面的文档里,反复出错的原因会被总结道 guides 目录当作思考指南,供下一次的 plan agent 去复用 |
| 17 fmfsaisai OP @ludage 所以我们是 coding-spec-driven 而不是单纯的 prd-driven, 我们的 plan agent 就是帮忙分解大任务,并跟你确认是否正确,确认之后再尽可能的高质量 coding |
| 18 mxT52CRuqR6o5 1 月 29 日 @fmfsaisai #15 模拟长期记忆和模型真正具备长期记忆还是有区别的，模拟的长期记忆模型每次都是以一个新员工状态去现学总结的长期记忆，读取总结的长期记忆的效果也依赖模型的上下文能力，但现阶段厂商提高上下文长度需要指数级地增加成本，屎山更高的项目效果 ai coding 实践效果就会很差，然而真人却有办法 hold 得住 |
| 19 fmfsaisai OP @mxT52CRuqR6o5 这个是大模型架构问题了,我们框架只能让 ai 尽可能的去像真人,让它尽可能不写屎山代码 |
Select Language