@zuokanyunqishi 是的，目前阶段，只要还是 LLM ，就不可避免的会出现上下文污染问题导致结果偏移，软件工程现在要解决的问题是如何组织合理的上下文让 AI 尽可能的聚焦，不然做的越多错的越多，最后的结果就是项目失控。

所有的目标偏离都是上下文管理的问题，https://www.dbreunig.com/2026/10/24/the-state-of-context-engineering.html 推荐一读

1. 这个不是问题，能高效生成了为什么还要手写。 2. 这个是你作为工程师要解决的问题，怎样让代码不啰嗦，让他变得符合你优雅的定义。你需要加 rule ，做好上下文管理。 3. 这个也是你作为工程师的要解决的问题，如何建立可信的验证机制，确保不出大问题。或者即使出问题了，如何快速识别和回滚。

我觉得一个很好的出发点是搞清楚有哪些是你日常花了时间和精力，并且对你有价值的事情。对我来说，记账是一个很好的场景，目前已经基本上交给 agent 了，每个月的账单直接发到一个独立的邮箱，脚本进行脱敏后，agent 自己处理。

https://cloud.google.com/security/codemender

magpie 直接通用代理一下就好了

^ 同上，手环和电脑提醒都叫不动，那就真没啥办法了。

^ 同上。 如果想要说什么，给自己几秒钟缓冲时间，不要脱口而出。

herdr

不知道为什么这么好的分享没有人回复。 每一点基本上都是我踩过的坑。 比较好奇有没有工具来管控 spec 的质量，目前看下来对于 spec 粒度有比较好把控的 engineer 基本上和 ai 协作的都比较好，而许愿式开发的 engineer 很容易陷入 AI 疲劳（摊子铺得太大且并行，非常容易失控） 还有把 session 内容沉淀成真正有用的 fact ，如何做召回验证，确保留存的 fact 不