@Seck 确实 我现在一行代码都不敲了

@b2byco 我看下来现在能做的事情 用 prompt + subagent 似乎也都能搞定。 主 agent 只需要负责推进流程，以 Claude 的上下文和模型能力，只干这件事基本没遇到过流程错乱的情况

手持 1+13
优点：无痛解锁，系统丝滑（安卓阵营里我觉得是最丝滑舒适的了），自带谷歌
缺点：拍照拉垮，续航抽奖

其他基本都无功无过 供参考

等会拿我们老系统试试，十多年的屎山，业务揉杂，能分析出来就说明真的有用。

@kera0a 没那么久 https://i.imgur.com/NIvxivj.png

现在阻碍业务开发这个岗位消失的问题就剩下两个了：1.大库旧代码更新维护以及程序逻辑关联 2.代码跟业务语义的关联
综合起来就是你要解决的问题，解决掉了绝大部分业务开发就可以转行了。
目前主流的思路有这么几个：
1.知识图谱
解决的是问题一，就是各种关联代码逻辑之间的关联关系。 我实际在生产项目上用过 code-review-graph 、gitnexus 等等 总体看下来效果差别不是特别大，只要不是微服务、大量 rpc 调用的项目准确度基本是可信的。rpc 目前市面的知识图谱试过一遍没有效果好的，如果有我没发现的欢迎指导。 但最大的问题是 ai 在调用关联关系的时候，图谱返回是全的，ai 处理会遗漏。当然这个问题很好解决，就不多赘述了。
2.LLM Wiki
其实期望上是解决代码到业务的关联。但其实本质上就是个文档自动化，不能直接解决代码到业务的关联问题。其他场景下倒是很好用，但是对团队里的人的习惯要求很高。毕竟读的是 diff 和注释+代码本身。维护起来没有想象中的那么方便
3.Business Rule Extraction （业务规则提取）
现在大体上两种思路，一个是确定性分析，但基本都是闭源产品，不知道怎么实现的。比如 Phase Change Software 反正广告吹的是能解决这个两个问题，真实怎么样不知道。 另一个是 ai 辅助识别，让 llm 去读代码，结合提交记录、注释然后生成伪代码+业务逻辑。这个反正我觉得很扯淡。
4.剩下的基本我判定为 ai 吹泡泡，为了吹牛逼而生的
比如软件数字孪生、在代码之上建一层语义抽象层（有点像 mcp ）等等，我觉得都很扯淡，至少目前看不到落地的可能逻辑

哦对了，还有一个思路，个人认为可以落地。但是如果没有 ai 之前落不了地，有 ai 也不行。
那就是 ddd
ddd 本身就是代码和业务之间的语义桥，提供了天然的模块边界。ai 可以非常方便的做各个聚合根对应什么业务概念。做代码跟语义的关联就会非常轻松。因为问题 1 程序逻辑关联其实已经能够解决了。
但是吧这东西好实践但是难落地，对人甚至整个公司从上到下认知的要求实在太高了。高层愿不愿意投入时间、人力、金钱，业务方是否愿意配合、有没有能力配合。缺一不可。


以上都是个人探索下来的拙见，欢迎交流

我也折腾了一圈，最后还是 todesk 最省心

@Rooger 解码之前我就知道是这家哈哈哈，我也是用的这个，买了好久了。我感觉这个比奶昔什么的都稳

软件/项目 不是大部分公司的核心竞争力
根本恶心不到的
我司某位同志有一个很形象的比喻，你在新街口放一坨屎，他能都卖出去。
绝大部分公司的软件/项目，单拎出去就是一坨毫无价值的屎。
你复刻一坨屎，谁也恶心不到，只会被人笑话这人真是个大傻子。

@fennu2333 #19 看起来不错，跑跑试试看

好奇，长任务流，是怎么控制上下文的？ yolo 完是在一个 session 里干到自动 compact 的么 还是会监控上下文用量启子 agent

所有的中转站都掺假。是所有，没有例外

@rocmax 实际在生产项目上跑下来，并没有想象的那么美好。 规则和实际逻辑不匹配是常有的事情，甚至 spec 更难懂，在大型项目上甚至有些绕的匪夷所思，生怕人类看懂。 原先以为是 speckit 流程太复杂了，换成 openspec ，虽然人要干的事变少了，但是规则质量更差了。

现在已经不敢随便把 token 给各种自研工具了

我现在在团队内部的方案是用 skill 管理 skill 。
写了一个专门的 skill 组，作用是上传仓库、拉取及安装、更新、分享。同时自动记录贡献者、review 、风险评估等，一个人定期处理 pr （这一步正在想办法用 ai 代替）
利用的就是人性的弱点 《懒》

@XuDongJianSama 除了这俩没有能打的了么，Google 家的怎么样

@XuDongJianSama 这个一直是这么做的，我现在是高强度用 claudecode 的 agentteam 所以 token 烧的快

@Heanes 落地页么，有，空了我整理一下传上去