AI 会犯错误，而且喜欢犯同样的错误，如何确保在更换模型、切换上下文的时候，AI 不再犯？ 最有效的办法就是，把 AI 犯过的错误记录下来，然后将它变成规则文档或者程序脚本，每次提交前都强制检测一次，成为门禁。 我当前的设计是，AI 犯错后会自动更新两类产物：1）rules docs，每次 AI Code Review 的时候，会加载这部分内容；2）governance scripts，将可程序化的检测工作全部变成脚本，例如 git commit 规范、大函数检测、单测覆盖、代码引用规范等等。 项目跑的越久，AI 犯错的概率就越低。

最近在使用一种和 AICoding 更好交流的方式，椅子上一躺，按住语音输入法，把自己要做的事情、为什么要做、解决什么问题、期待长什么样子、喜欢什么样子的风格、如何来验收等等自言自语聊上几分钟，不停补充要求，然后把这些杂乱单重要的上下文一股脑给到 AI ，效果往往会比打字一句句聊好太太太多了!

到底要不要人工审阅 AI 生成的代码，我是这么看的： - 在 agentic coding 时代，自动化测试变得尤为重要。所有能被自动验证的行为都应该被验证。AI 写单元测试很容易，但对于更复杂的集成测试，仍然需要人去搭建——这些工作很多是一次性的，但也有些需要跟着项目迭代。 - AI code review 能搞定 90% 过往需肉眼检查的内容（语法、注释、边界条件、logging、etc），当然前提是团队提供了严格的代码规范。这并不难。 - 仍然需要人把关的那 10%，是「架构设计」。AI 能写出完全符合代码规范，但是架构一团糟的代码。而「设计」往往项目甚至单个功能相关的，很难被规范化。这里人类的经验就很重要了。 - 如何让人从 AI 生成的巨量代码中快速提炼出架构设计？好的做法是让 AI 往 commit message 里加入「修改了哪些代码」的总结，并提炼出架构图。很多 AI code review 产品已经是这么做的了。人不再需要去看代码，看总结就行了。 - 很多场合下，的确没有必要人工 review：比如一次性脚本、使用成熟框架（Django, React）的项目等等。对于那些复杂且会长久维护的项目，人类 review 是必要的，但并不等于人要去读每一行代码。 - 最好维护一个包含设计选择、代码结构的文档，让 AI 实时更新。这对于人和 AI 都有极大帮助，能减少很多不必要的 turns 和上下文开销。

用 ChatGPT 生成 PRD，再用 Cursor Agent 自动实现，10 分钟就能搭建一个 CLI 工具原型 这是 AI Code Guide 里“vibe coding”实战部分的演示效果 这份开源指南系统地整理了 AI 辅助编程从工具选择到实战流程的完整方法论 核心理念是“规划先行”：不是直接让 AI 写代码，而是先用 ChatGPT 生成产品需求文档和任务清单，再让 AI 按步骤实现，确保项目始终保持清晰的结构 指南覆盖了从零开始的完整工作流：如何选择合适的 LLM 模型、编写有效的提示词、设置项目规则避免幻觉、处理错误和 Bug 还详细对比了 Cursor、Windsurf、Claude Code 等主流工具的使用场景 把 AI 编程从随机碰运气升级为系统化工程实践，正是这份指南试图梳理清楚的方向。 GitHub：

重新给新朋友介绍一下我过年期间做的 Kaku，一个安装后无需配置就可以使用的 Mac 终端，对于 AICoding 友好，性能体验均不错，结合我自己的编程习惯做了不少顺手的优化，也是我做过的最复杂的一个项目，开源持续至今迭代 21 个版本，保持 0 issue 问题，欢迎体验。

这期潮流周刊封面图拍摄于昨天去我的精神家园-王小波的书店，非常感谢有小伙伴指出之前几期周刊有点水，最近沉迷到 AICoding 了，接受批评，以后还是保持内容更有趣一点好，也让自己在代码之外多去看点好东西，不能丢掉人文的东西，争取也成为大家的小精神家园。

读到 1991 年 March 的这篇论文《Exploration and Exploitation in Organizational Learning》，讨论组织中的 EE 问题： 任何组织都面对一个问题：应该如何分配资源？ - Exploitation: 把资源花在改进已有做法上 - Exploration：把资源花在尝试新东西上 论文中的互相学习模型非常有意思： 每人对现实有自己的信念，还有一个「组织代码」（code），可以理解为组织的共识知识库或者集体常识。 个体会向code学习，新人进来之后慢慢被组织同化，这叫社会化。同时，code也向那些知识得比自己多的个体学习，这叫多样化。社会化太快的组织，code还来不及从个体身上学到东西，个体就被同化了，快速社会化杀死了多样性。 在读这篇论文的过程中，不断联想到现在AI与人的关系。 人就像论文中的个体，AI就像是论文中的组织code。 面对一个个「问题」，我们快速滑向了「AI」先思考，我们再「点头」称赞的「快速社会化」境地。 以前身边的一些朋友，认知结构和表达风格十分鲜明，最近在针对一些问题在线讨论时，明显感觉到对方返回的消息是「AI」，对方那个鲜明的「个体」不见了，他被AI同化了。 反观自身，我也陷入了同样的境地。 这种情况，非常不对劲。论文对EE问题的解法是制造「慢」：慢速社会化让个体在被同化之前有时间贡献多样性；人员流动引入新的差异来源；容忍暂时的无知和低效，为长期的改进保留素材。 两个结构的类比，虽有不同（我们不是为了提升AI「Code」而努力），但这种被「同化」的境地，值得警醒。

Claude Code 写到一半想换 Codex，项目怎么做的、哪些办法试过没用、接下来还有什么，又得重新讲一遍。 发现一个 开源项目 ai-memory ，会把这些内容整理成 Git 管理的 Markdown Wiki，让 Claude Code、Codex、Cursor 等 20+ AI 编程工具共用项目记忆，不过不同客户端的接入方式不完全一样。 可以自托管在本机、Homelab 或 VPS；远程访问记得配置认证和 HTTPS。不接云端模型也能记录和搜索。 👉 #ClaudeCode# #Codex# #AICoding#

请来继刚、歸藏、橘子对谈，几个思考： 1. 让 AI 真正落地的不是产品，是服务 2. 企业 AI 转型，只需要搞定 5% 的人 3. 越土的行业，AI 越吃香 4. 卖 Skill 给个人用户，是个伪生意 5. 别人的 Skill 再厉害，也进不了你的工作流 6. 下一张社交网络，一半节点不是人 #aicoding# #易论AI# #归藏# #colaOS# #李继刚#