Daily Reading

Daily Reading 20260330 Thoughts on slowing the fuck down fuck 含量极高的一篇文章~, 探讨了agent带来的技术负债. 过去我们人开发项目的时候, 会由于技术负债的痛苦不得不对项目进行迭代/重构来减少负债. 但现在 完全由AI开发, 由于AI只做风格迁移, 也会产生技术负债, 只是这种负债的痛苦我们不再需要感知, 最后的结果就是改不动, 无法继续迭代. 当然这里有人会说, 现在有 很多工具, 像superpowers, ce, gstack, 都可以来工程化, 更好的理解, 迭代项目. 这些工具都能很好的教LLM基于你的项目来写需求, 但我觉得这里有个问题, 我们使用的时候不得不维护大量的文档来构建项目的知识, 但实际上"A sufficiently detailed spec is code", 代码永远都是最新的规范, 而我们维护的大量md其实存在新鲜 度的问题. 当然, 我们可以做一个post-hook来更新, 但这里也正是问题可能出现的地方. 另外, 最近nodejs社区也有关于拒绝在node.js core中使用AI生成的提交的请愿.

Daily Reading 20260319 How coding agents work 虽然相关的内容都已经掌握了, 还是重新review了下有没有什么概念是遗漏的. You Might Debate It — If You Could See It 这个说了个有意思的现象, 如果你能够看到, 你就可能会质疑合理性. 但如果你看不到, 你可能会选择默默接受. 这个本身适合解释很多社会现象, 这里就不讨论了. 回到编程上, 就变成了, 如果给你制定规范, 你可能会质疑合理性, 但如果我说我给你提供了一个Skill, 你可能就高高兴兴的接受了我制定的规范. 我们在使用开源的Skill时候, 很多时候都默认的接受了Skill开发者的品味和审美, 无论好坏. A sufficiently detailed spec is code 作者通过OpenAI的Symphony例子指出, 最好的规范文档是代码本身. 我最近在现有项目上使用claude code 还是倾向性于拆小需求给他, 因为我之前追求构建好完整的项目理解(references)后再试试能不能让他自动修改完整需求. 但我发现, 要在一个已有的项目上构建完整的, 用于LLM理解的规范, 本身就是一件麻烦的事.

Daily Reading 20260311 最近有些忙，下面的内容不全是今天阅读的。 Beyond Language Modeling: An Exploration of Multimodal Pretraining 这个论文我最早是在公众号上看到，标题是"追逐 AGI 是错的"，我一开始还以为 Yann LeCun 大佬有发表了什么重要概念，结果过去一看是关于多模态预训练的。只是说 LLM 存在实用上的天花板，需要构建能够理解和推理物理世界的系统。结果是很典型的国内公众号标题党。 12 Factor Agents 参考 12-factor apps 写的面向 AI Agent 工程的 12 条原则。最近聚焦于关于 Agent 工程的内容，感觉之前自己写的 Agent 怎么全是反模式。 A Guide to Which AI to Use in the Agentic Era 主要介绍应该使用什么样的 AI 应用，适合作为了解用的读物，我没有仔细看全文。 Beyond Prompts and Context: Harness Engineering for AI Agents Harness Engineering，最近大热的名词，不得不说还是很贴切的。LLM 作为烈马，怎么设计 Harness 非常关键（这里我没找到中文的翻译，用马具也不太合适，就直接用英文了）。 Inside Claude Code: The Architecture of an Autonomous Agent ...

Daily Reading 20260305 Agentic Engineering Patterns 这俩天抽空把已经更新的都看完了，整体还是有收获的。原则上，“Writing code is cheap now”, 但我们还是要为生成内容负责，这应该是共识。同时，之前在 golang-dev 中看到过相关讨论， Ross Cox 的观点认为我们不应该添加 “Co-Authored-By agent” 在 commit message 中， 这和我的观点也是一致的。由于 claude code 的默认提交风格总是会倾向于添加 “Co-Authored-By”, 最近我在自己的 plugin 中严格禁止了这一项: 1 2 3 4 5 ### Rule: No AI Attribution **Never add `Co-Authored-By` footer for AI agents** (Claude Code, GitHub Copilot, OpenAI Codex, Cursor, etc.). AI is a tool, not a co-author. The human takes full ownership of every commit in their repository. 第二部分介绍了测试优先的模式，这我觉得也是非常重要的，通过 “Red,Green,Refactor” 来保证 AI 生成的质量。同时在会话开始的时候，优先让 AI 跑一次测试，这样后续会话 AI 都倾向于用测试来验 证改动。虽然我很认同这个模式，但实践起来还是有难度的，比如在我日常的工作中，经历的很多项目可能都没有很好的测试，这时候我先花时间跑一边测试的生成又好像有点麻烦，最近在思考怎么增量 的，动态的做这个工程。 ...

Daily Reading 20260303 An AI Odyssey, Part 1: Correctness Conundrum 这篇文章探讨了 AI 面临的准确性困境，即在特定领域其行为是可以被有效界定或者验证的，这个问题仍然不是很好解决。在编程领域目前常见的方法是通过 TDD 来一定程度的保证准确性，通过 “Red,Green,Refactor” 来保证 AI 的输出准确性。 Giving LLMs a personality is just good engineering 这篇文章指出我们在提示词里设计让 AI 扮演角色其实不是 cosplay 而是约束并引导模型输出的有效手段。 Why we hate AI-assisted articles 我觉得这里的观点很对，“如果你自己都不愿意花时间去写，别人为什么还要花时间去读呢？"。这也是最近为什么我暂停了用 AI 写 blog 的想法，转而简单的 daily reading 模式。但我觉得这其实是可以探索或者试完的一块内容，为此我还特意打开了 blog 的作者显示，区分我和我的 claw 写的内容。另外我现在的观点是 “AI generation is fine, BUT references first”。 Agentic Engineering Patterns 最近开了 Simon Willison 大佬的赞助订阅，立刻就收到了有用的东西，里面的内容我还正在研究。

前言 之前乘着春节的档期部署了自己的在云上的 openclaw，取名叫小蓝。完成后的第一个任务就是让小蓝自动写博客。目前而言，整个 skill 还有很大的进步空间。特别是我用 cc 开发的 skill 在 openclaw 中无法进行通过对话的方式确认主题细节。后续让小蓝写了几篇，AI 生成的痕迹还是有的，所以调整了一下策略：一个是把参考资料都放在最前面，这样哪怕读者一眼丁真了，也可以直接跳转原文，至少原文还是有价值的。第二个是在最后加了"AI 生成"的标识，如果读者看到最后才恍然大悟，至少证明了 skill 的成功。 好了，上面都是题外话。其实我觉得现在这些生成的 blog 质量都有点低，因此才有了今天的内容，Daily Reading。后续争取每天都能够更新，把今天的阅读内容做一个简单的摘要和分享，先"人工智能"（当然，我其实是提前丢到 notebooklm 里阅读的）。 Daily Reading 20260302 Expert Beginners and Lone Wolves will dominate this early LLM era 本文描述了 AI 发展后续的一个有意思的现象，程序员将出现两级分化。一边是专家型新手（expert Beginners），借助 AI 编程工具感觉自己无所不能的初级开发者；另外一边是独狼开发者（Lone Wolves），经历过 AI 时代之前的历练的资深开发者，他们能够开一人公司，指挥多个 agent 来干活。换句话说，中间的那部分会逐渐消失，出现断层。我不禁思考我在哪个层级，想来还是在这个中间层，原来我还是未来的稀有种。 When does MCP make sense vs CLI? 这个讨论其实也非常有意思。一开始 MCP 出来的时候，其实大家都在追求构建 MCP。但是到了 Openclaw，或者其实随着 skill 的提出，MCP 的优势就开始动摇了。我现在在公司的开发 Agent，就是把所有需要的接口做成了 MCP 的工具，来拓展部署在线上的 Agent 的能力。但我最近接触 cc 的 plugin 之后，如果我们每个人都用 cc，那其实开发一套 cc 的 plugin 就可以，这里可以要 MCP，也可以不要。 ...