想请教大家的ai coding工作流

想请教大家的ai coding工作流 图片 1

日常工作和个人项目都会用 coding agent。最近遇到一个挺困扰的问题,想请教一下有经验的工程师。 我的体感是:在已经比较成熟、抽象比较清晰的代码库里,AI coding 用起来很顺手。但在让 LLM 从零开发的项目里,一方面,随着功能增加,我会逐渐失去对代码库的掌控。另一方面现在即使是很好的模型也经常生成一些非常complex and defensive的代码,加很多一看就不合理的fallbacks。 一开始也会认真讨论设计、review plan,当时觉得自己都理解了。但过几天继续迭代,就开始跟不上:这个逻辑放在哪里?为什么又多了一个模块?新增功能应该改哪一层? 最近在读《A Philosophy of Software Design》,虽然是大模型之前时代的书了,但里面关于抽象的讨论很有共鸣:好的设计好的抽象,应该让开发者比较容易判断,为了修改某个行为,需要去改哪些模块。回头看自己,有时候连项目到底有哪些模块都快记不清了😂 我感觉这里有两个互相关联的问题: 代码本身可能在变得难懂。每次功能都能跑,但模块边界逐渐模糊,职责散落在不同地方,后续修改越来越费劲。 即使代码结构还算合理,我自己也没有建立起对它的熟悉度。很多实现决策和调试过程都是 agent 完成的,我看过解释,但下次遇到问题,还是不知道从哪里入手。 第二点尤其让我担心经验积累。我理解工程判断力、设计上的 taste,需要从具体实现、踩坑和修改中慢慢长出来。但现在很多时候,我的工作变成了:描述需求、看结果、继续提修改。 功能确实做出来了,但我不太确定,自己从中积累了多少能迁移到下一个项目的经验。 想请教经验比较丰富的engineer: 连续迭代一个项目时,怎么让自己始终跟得上代码的变化?设计文档和 plan 之外,还有什么有效的习惯? 出现哪些信号时,你们会暂停加功能,先重新梳理结构? 对工程经验还不够丰富的人,怎么在使用 AI 提高效率的同时,继续积累设计和调试能力? 尤其想听一些具体例子,想参考大家真实用得下去的工作流。 #aicoding #codex #claudecode

添加评论
点赞收藏
点踩分享
评论13
?
参与讨论
核心的职责、抽象和架构,都自己来设计。举个例子:引入 api service entity impl manager model 一批的命名和职责规范,强制 service 无状态、manager 有状态,强制数据流向和调用链路都保持单向;每个模块或者目录用 api 导出能力。让 AI 把它想写的类型和方法都填进你规定的框架里,这样你看一眼目录和命名就知道这个大概是做什么的、可以调用哪些底层能力、会被谁调用、可以对外提供哪些能力。
9小时前
回复
感觉这个思路也对用agent搞科研很有启发
6小时前
回复
深有体会。这个时候do not就已经不太管用了,你需要给它提供一些优秀实践,白名单比黑名单更有约束力
10小时前
回复
这里的白名单在什么时候注入呢?解决具体问题/在某个具体环节比如设计阶段/还是说全局的放在agent.md中呢
3小时前
回复
定期重构,除非是一开始就非常明确架构的项目,否则迭代过程肯定会遇到技术债的,另外就是涉及数据流的环节可以参考响应式设计
11小时前
回复
本科生小白想问一下 什么时候重构呢?
11小时前
回复
我说说我的方法。 直接以文档构造角色职责。 从零开发项目起,包含planner,controller,builder,reviewer等开发角色。 每个角色自有其职责。 做好每任务批次文档交接。 交接文档细致一点。 也就是说任务进度只存在本地,不存在上下文里。 每换一个新窗口,都能直接从断点复原,瞬间接管。 总结一下,planner管需求落盘,controller管技术细节进度任务派发,builder管代码编写,reviewer管代码审查。 如有需求先找planner进行需求登记,planner如实登记后流转给controller,然后再安排技术细节。 自做软件如图
12小时前
回复
听上去很有趣。我想请教下,每个agent是怎么彼此交流的,他们是一对一沟通还是有个人群聊?另外人类在这个环节怎么参与?
12小时前
回复
文档管理是必须的,特别是架构一定得自己看得懂为什么。0-1的阶段ai是基于当时的功能去搭一个架构,但后面新增功能的时候,ai大概率是基于现有架构去加而不会考虑目前的架构在新增功能下是否需要重构或者优化。这个时候就需要人来判断了。还有就是在修bug的时候一定要看清楚修复方案,特别是ai给的方案是否包含兜底方案,兜底方案可能会掩盖真正的问题,而且还会引入没有必要的架构导致整个逻辑变得复杂。最致命的是一般兜底方案ai都说得信誓旦旦不做不行
1小时前
回复
这不是一个ai写代码问题. 这是一个项目管理问题。所以这也不是一个skill或者一个什么神奇的方法就能解决的。有时候不是不会,可能就是花的时间精力,和管理能力确实还没到不用太着急也,该学习学习,该做实验做实验,该放下的放下就好。到了管理岗,分配资源、预期管理都是需要的。有的时候一个模块有点儿别扭,确实可以改,但花的时间精力资源,跟最后改出来得到的收益不成正比。那可能就要退而求其次。有的大改动,他可能就是得有足够的收益才能让他值得启动的。
2小时前
回复
使用ai是一门技能(驾驭工具的能力),架构设计是另一门技能(认识事物本质的能力),两个技能都要练都,互相没法替代,所以最好不要混在一起讨论。结果差可能是ai用的不够好,也可能是架构设计没经验,也可能是两个都差..总之两个都要练,要互相滋养,只有两者都够好才能用ai做出好的系统。
3小时前
回复
我觉得定期重构+控制输入输出+真实生产实测。先跟agent聊清楚你要什么,架构是什么,到底要做个什么样的产品,然后再按照软件工程的流程,确定规格,开始实施。你的角色在变,agent的角色就是你的下游,那么这个情况下,你不可能逐字逐句的去审agent的文档,更不可能逐字逐句的去审查代码。所以你能做的其实就是确定好输入,确定好验收标准,确定好重构的时机和你真正想要的结果。其实你这个问题并不是一个软件开发的问题,而是一个项目管理的问题。但是放到如今的vibecoding上,项目管理更重要了
4小时前
回复
一般花非常多的时间90%,左右在方案设计,起码知道竞品怎么做的,方案如何,找出指标对齐。然后自己再做开发方案。开发方案先简单实现能过测试case。最后再架构优化让它可维护方便扩展低耦合。然后后面ai就在低耦合的框架内增减不会乱改了。
4小时前
回复
设计clay,用hook钩子,每次任务必须先建BR和progress,每次任务结束都必须commit和push。建立项目的知识库,从PRD、技术文档、设计文档、任务记录、踩坑记录,所有细节全部都记录下来。
6小时前
回复
失去掌控,是因为你没有模块化。设计的时候,仍然需要它先写high level design,然后你要把控模块还要api,这些是高leverage的地方。基本上原则就是open to extension and closed to modification。
6小时前
回复
增加多层测试体系,unit test, component-level test, end-to-end test,regression test。 当测试失败数量持续增加、相同类型的问题反复出现,或者修复一个问题经常引发其他模块回归时,不应只继续补测试或修 bug,而应触发 Architecture Review,分析是否存在模块耦合过高、职责边界不清、接口设计不合理或技术债积累等问题。
8小时前
回复
你直接按照架构那一套给它强制定义架构和文件存储,然后再建一个temp存每次AI编程都改动
9小时前
回复