AI开发大半年了，唠唠嗑

开发调优
,
1

用了大半年的c、c、g工具。看到了铺天盖地的媒体，说什么什么工具能一键做出个什么什么东西。我目前有一个比较自由的项目和自己接一些小项目做做，真的90%用于编码就知道里面的苦了。我总结了几个我认为头疼的点，还没有找到完整的解决方案（有的时候真的在想：老A是不是为了市值在骗咱们，几个月Claude的迭代不写代码，这方案得写的多好？）

欢迎各位佬友一起讨论，开发过程中遇到的问题和解决方案：

  1. 上下文难管理，每个任务有时候不需要去加载那么多的上下文，而频繁地自行去切换又很麻烦。我们的上下文都在一个黑盒中。一旦切换对话，很多内容将会重新了解。
  2. 道理我都懂，很多时候还是会偷懒，给 AI 的指令都是一些约束好的指令，而不是充分发挥 AI 能力的指令。或者说一些比较简单的话，让AI去完成某个目标。而充分发挥 AI 能力需要大量的提示词经验沉淀和高昂的沟通成本
  3. AI 完成任务缺乏强约束的流程化控制。智能体在目前的时代仍然显得不稳定，现在的 Agent 和 Skill 都有概率不生效。
  4. AI 虽然能够拆分 Todo 项，但是一旦误判了某个结果，修的时候就没有条理了
  5. 自动化测试难控制,而且自动化测试巨烧 Token
  6. claude code是我用来体验最好的。用glm的模型，效果也不差。但是现在正是百花齐放的时候，从经济或者特性的考虑上有的时候某种方式更优，有的时候又比较纠结。

最近在设想一个产品，基于 VS Code 进行改造：

  1. 多节点的门禁系统：用户必须确认 Agent 给他的方案，我相信大多数场景下：“慢就是快”
  2. 产品架构定义：可以自由地讨论产品的方向、市场调研以及业内的最佳实践。产出物从竞品情况到已知的市场环境数据到产品愿景 Slogan等，从主体功能到 MVP范围 定义，再到页面风格以及建议参考（AI自己设计实在不敢恭维，Gemini也照喷）。
  3. 用户确认后生成前端原型图，在浏览器中间打开让用户去确认，并且有像 VueTools 一样可以点击位置定位Dom允许用户并提出问题、进行修改的能力。
  4. 然后确定技术架构，可能需要准备一些开源的底座架子。
  5. 根据用户的需求开始拆分 User Story。再由用户确认后，生成技术方案（务必包含数据库设计）。
  6. 用户确认后开始基建搭建并进行测试。跑通后，根据多 task 并行设计和开发，设计会挂在task的详情里
  7. 开发完成后进行自行测试，并由测试 Agent 介入。
  8. 测试提完BUG，修复后形成问题总结，询问用户是否用户更新提示词工程
  9. 用户验收，提UserStory/Bug

其他设计：

  1. 提供轻量的项目管理工具，每一个功能都会有一个 user story（附带产品文档），在用户确认方案后，系统会自动生成 task（附带技术文档）。
  2. bug可以追踪，AI的处理方案也有记录，如需人工介入也方便一些
  3. 兼容Agent sdk和Api
19 个赞
2

我是先从需求生成 spec 文档
然后基于 spec 文档用 ccw、superpowers、trellis 这种开发
能好一些

2 个赞
3

确实，虽然AI编程效率特别高，但是这是局部效率。
整体效率（交付需求，上线）其实并不高，一方面是因为编程占比并非100%，另一方面有很多出错、不稳定的地方，还是需要人工确认。

但是这或许是科技发展的必经阶段，只有大家经历过，参与的人多了，才能更好的发展

1 个赞
4

上下文难管理：一般是做plan 比如spec，或者项目本身就是上下文，通过快速search与匹配（ACE建立项目索引进行快速匹配，或者https://linux.do/t/topic/1610998 ，现在只能说大的拆小的一个个完成，自己得做好开发计划与架构规划；

沟通成本这个是没法避免的：除非你给他现成的参考项目以及目标项目，或者开发规范比如context7进行规范约束，但它本质上也是一种提示词冗余，说白了就是模型本身训练的内容还是旧的+实时联网进行对齐；

自动化就是烧token呀，现在流行养虾（openclaw）就是烧token，不过和几年前比token的使用已经翻了不少倍了，最初的chat–agent–code agent–mulit-agent–… 放心后续token还会越来越便宜

另外，现在不考虑codex吗，目前能薅赶紧薅…

1、高强度在生产环境vibecoding了大半年，具有丰富的vibecoding经验，可解答世界万物 - #11，来自 xingtong8142

2、万字长文：2025 年，我对 AI 编程的全部理解——Part 1

3、openclaw 创始人3小时深度采访 (opus 高质量翻译)

2 个赞
5

我最喜欢给版本答案了：其实微软占尽生态位 Github VsCode Copilot Azure 完全可以孵化出更加逆天的以 Issues 为中心的开发工作流，因为 Issues 就是 Prompt 是 Session 是 Context 是 Plan 是 Design 是 Test 是 Agent 本身，再加上 GitHub Actions 的 Feedback 简直无敌。既然有我吹的这么厉害，巨硬还不跟上，简单查了下 巨硬就是这么做的哈哈 - GitHub Copilot Workspace。 不用 GitHub Copilot Workspace 的话 也可以使用 CLAUDE SDK + Issues + GitHub Actions 实现这套云端工作流，本地的话使用 VsCode + Aagent + GH 也是一样，只不过比较原始抽象就是了。

4 个赞
6

我在调研的时候也试过这一套，在仓库管理、分支、CI/CD方面确实很爽。但是苦恼于已经买了几个会员了。实在吃不消，就像我说的，百花齐放

7

我也会先plan建spec文档，对齐后plan技术方案文档。但是这几个工具我都没用过，我去了解下看看，感谢分享

8

是的，现在厂商鼓吹概念，自媒体博眼球，大家预期还是有点高。真正工程化开发还是得琢磨琢磨

9

codex也有在用，响应太快了，极度舒适。这些是现状，但是没能解决问题

10

各位佬友的回答都好精彩，先马后看！

1 个赞
11

我反而不喜欢一上来就plan，除非是简单任务。复杂任务我都让ai自己发散一下，充分利用ai的泛化能力。就像复杂算法问题和性能问题，第一时间你不可能找到最好的，也不可能是最完美的。而这种方案如果你一定下来，你后面改就会非常麻烦。唠嗑唠完了，最后再定plan

12

我把各种skills，自定义指令框架全卸了，纯净codex和claude code做了秒杀算法优化和性能优化，然后反过来让ai根据我的习惯然后我和ai协作的可优化点，然后做成skills和自定义指令。这样就用起来就不需要我反复提醒，然后衔接spec框架或者自己做就非常顺畅
如果配合不顺畅，我不建议装任何spec框架。完全是负优化

13

你这怎么结合，既然都生成了需求spec，用后面那几个意义不是太大吧。。

15

因为需求spec的粒度并没有那么大，是建模、api设计这一层
实际实现需要结合项目代码，使用的第三方库等，还要考虑代码风格，单元测试这些，还是需要单独的计划的

16

那你需求的spec用的啥，后续怎么维护的？

17

superpowers应该能解决你大部分问题，上下文问题用codex或者amp也可以解决。再加上论坛佬友的llmdoc作为参考，整体就很丝滑了。你说的问题都可以解决

18

可以试试GitHub出的spec-kit.它是将需求通过规则化成逐个小任务。并自动建立关联和依赖来进行逐步开发。很方便。可以试试

1 个赞
19

spec 也是直接用 ccw 脑暴出固定格式的文档