每周文摘 01312026
又开始玩魔兽，还是念念不忘，那就玩玩吧，我也不会沉迷的。
从 RSS 订阅上了我也开始做了减法，包括公众号上的关注，精读为主，不要 FOMO。
本周观影和阅读
- 《咸的玩笑》：读着是不错，但是其实内心也有些犹豫，总感觉是有点中老年油腻的感觉，写的这个故事和文字，我过去也没看刘的文字，这是第一次
- 《我的美食向导》之潮汕：去过一次，但是这种人文结合美食记录片，完全不一样，而且看到的吃到的也和自己不一样，能看，但是和舌尖以及风味人间还是不一样的片子
- 《机动部队 PTU (2003)》：杜琪峰的老片，情节有点空，不算精彩吧
本周阅读
安东尼·波顿的书 《安东尼·波顿的成功投资 》（雪球上赛艇队长的 2025 年度总结提到的）
- 《Build LLM from Scratch》 看了个大概，不在自己知识能力范围内
- 《Facilitating Software Architecture - Empowering Teams to Make Architectural Decisions》也在看看这本，没看下去，不是我想要的那种书
本周播客
- NA
本周胡思乱想
- 如何让小伙可以尽快的成熟，大了说就是世界观和人生观，小的说就是对于这个社会和自我的认知，能尽快找到自己的方向，或寻找自己的方向
- 心里放不下执念，还是没到位，管理是练心力
本周文章
Coding Agent 时代，App 的核心竞争力是什么？
不断的看到这个观点，就是单一代码技能是不适合未来的生存的，需要综合技能的考量。
Claude Code 并没有让 App 开发这件事变得没有价值，它只是消灭了平庸的重复造轮子，将竞争的维度拉向了两端：一端是更底层的系统架构与质量保障，另一端是更上层的用户洞察与品牌情感。夹在中间单纯靠「写代码」生存的空间，会被挤压地越来越小，甚至消失。Beads - A memory upgrade for your coding agent
上面这个工具是从从 Note-driven agentic coding workflow using Claude Code and Inkdrop 看到的，这周末可以试试，同时也仔细再看看作者提到的 note-driven coding workflow.
1. Request a plan - Run the /plan command with your task description
2. Plan is created - Claude Code analyzes the codebase and generates a detailed implementation plan
3. Saved to Inkdrop - The plan is automatically saved as a note with status none
4. Review and confirm - Read the plan in Inkdrop's markdown renderer, then confirm to proceed
5. Execution begins - Status changes to active, work starts
6. Progress updates - Checkboxes are checked off, deviations annotated, blockers noted
7. Completion - Status changes to completed, outcome section appendedI replaced a $120/year micro-SaaS in 20 minutes with LLM-generated code - The Pragmatic Engineer
SaaS 软件在 AI 时代也许会日渐势弱，因为被复制的成本太低了，是好事还是坏事？好的一方面是使用方也许某种意义上收益，坏的方面是也许没人去创意和推出新东西，被抄袭的成本太低，这个也是 AI 时代需要解决的问题，开源软件也是类似问题，但是 AI 时代需要我们有创意和品味，而不是需要一个代码的“苦力”。
生成式 AI 正在重塑软件开发。Claude Code、Cursor 和 Lovable 等 AI 辅助编程助手让用户几乎无需手动编码就能将其意图转化为可工作的应用。这种软件构建方式被称为 Vibe Coding。Vibe Coding 降低了软件开发成本，但也改变了用户与软件生态系统的互动方式。传统的软件开发模式中，开发者选择开源软件包、阅读文档，与维护者及其他用户互动。在 Vibe Coding 下，AI 智能体可以直接选择、组合和修改软件包，人类开发者可能不知道使用了哪些上游组件。这就引发了一个开源软件的可持续性问题。开源软件项目依赖于用户的参与和互动——文档访问、bug 报告、公开问答和声誉——维持维护和获取报酬。如果 AI 取代了人类用户之间的互动，那么旧的开源软件开发模式将会彻底改变，开源软件的可用性和质量将会下降。中欧大学和德国经济研究所 Bielefeld University and Kiel Institute for the World Economy 的研究人员在 arxiv 上发表研究报告认为，Vibe Coding 将会杀死开源。
https://arxiv.org/abs/2601.15494Running an Engineering Papers Reading Guild at Zalando
每个公司的科技部门都需要这样的读 paper 俱乐部，跟踪业界最新进展，促进交流提升大家的能力；同时，里面提到文章我也想读一读。
AI Agent 的操作系统时刻
Agent OS 这个提法对不对？是不是确定性的方向？我不知道，但是文章本身很清晰，切入的角度很好，真正底层技术才是常青树。
* 内存管理将是最复杂的技术战场——谁能让 Context 像虚拟内存一样透明地换入换出，谁就能定义下一代基础设施
* 数据库是确定性最高的商业机会——PostgreSQL 不仅是存储，更有潜力成为 Runtime
* 进程管理表面红海，深水无人——当 Agent 成为长期运行的服务，真正的调度和恢复需求才会浮现
* I/O 的终局不是新协议，而是 Agent-Native CLI —— 55 年的 Unix 哲学不会被轻易颠覆
* 信任层将成为企业市场的入场券 —— 沙箱是底线，可观测性才是关键AI Agent 的上下文管理，这文章总结的不错，对我来说是个好的入门，短期和长期记忆分别如何做，但是在具体的会话中如何使用短长期记忆的内容（Google 了一下 获取和注入：Retrieve - Before the agent responds to a new prompt, search the memory database for relevant past data using the user's current input; Inject - Add the retrieved, relevant information into the system prompt or conversation context.）。
跑超马的都不一般。
生产力方面，如何做好笔记，有自己的一套流程和配套的工具体系，包括自己写工具，如：聚合抓取信息汇聚成 epub。
一个好的笔记系统不仅仅是工具的堆砌，更是信息的流动。我的工作流包含五个阶段：
* 捕获：极低阻力地快速收集。
* 存储：将待处理内容归位到合适的介质。
* 处理：提炼、消化原始内容。
* 回顾：建立连接，内化知识。
* 产出：用笔记解决实际问题，形成闭环。
待处理的内容通常比较长，或者是非母语的内容，为了提高效率，我会先让 Gemini 对内容进行压缩，如果感兴趣，再去看原文，然后与 Gemini 就里面的内容进行深度的交流。这是一个例子。交流完后，通常会有这些产出：
* 一篇原文的精简版（放到笔记 App 里）
* 一篇讨论后的笔记（放到笔记 App 里）
* 一些原文的精彩摘录（放到笔记 App 里）
* 方便录入到 Anki 的卡片（整理成实体卡片）
* 相关推荐
处理后的笔记，我选择存放在 Bear 中。
* 为什么不选 Obsidian？ 它确实功能强大且免费，也有丰富的插件系统，但我用起来总觉得不够「舒服」。
* 为什么不选 Apple Notes？它对 Markdown 的支持不友好，内容也有点封闭，写作体验也不如 Bear。
选择 Bear 还有一个好处，它的笔记可以很方便地导出为 Markdown，方便二次加工和后续迁移。孤立的笔记是死的。让笔记活过来的关键是Link（链接）。因为 Bear 的笔记都存在本地的一个 SQLite 数据库里，所以可以很方便地读取和处理。我写了一个 js 脚本，将 Bear 里的笔记内容向量化（Vectorization），然后计算余弦相似度，自动生成「相关笔记」列表。
把笔记存进去如果不看，那意义也不大。为了方便回顾，我做了一个 Web App（notes.limboy.me），每次随机展示一篇笔记作为起点，然后通过「相关笔记」进行漫游。同时也会在碎片时间把上一个阶段生成的卡片拿出来翻一翻，加深印象。
笔记不是目的，它是为了帮助生成洞见（Insight）、新的看事物的角度和强化知识网络而存在，最好的方式就是输出，比如写文章、做分享、做决策等。以写文章为例，如果想写一篇关于「习惯养成」的文章，不再是面对空白文档抓耳挠腮，只需在笔记库里搜索「习惯」、「行为心理学」，把相关的 5-6 个笔记块（料理包）调出来，重新排列组合，加上新的连接词，文章的 80% 就完成了。
如果没有一套运行顺畅的笔记系统，没有为消化笔记专门留出时间，没有输出的压力，那么笔记的价值就会大打折扣，再好的工具也无法做到第二大脑。希望这篇文章能给你带来些帮助和启发，如果你有好的想法和经验，也欢迎分享。A few random notes from claude coding quite a bit last few weeks
周四早上读了一下，挺长的，最后留的几个问题有点意思，回复第一条是 Boris Cherny 的，来自 Anthropic，更多需要通才和资深的人，横跨多个领域；代码完全都可以用 AI 实现，质量在持续的提升随着模型的改进，提效和提质并重。
HN 讨论：https://news.ycombinator.com/item?id=46771564
Questions. A few of the questions on my mind:
* What happens to the "10X engineer" - the ratio of productivity between the mean and the max engineer? It's quite possible that this grows a lot.
* Armed with LLMs, do generalists increasingly outperform specialists? LLMs are a lot better at fill in the blanks (the micro) than grand strategy (the macro).
* What does LLM coding feel like in the future? Is it like playing StarCraft? Playing Factorio? Playing music?
* How much of society is bottlenecked by digital knowledge work?As always, a very thoughtful and well reasoned take. I read till the end.
I think the Claude Code team itself might be an indicator of where things are headed. We have directional answers for some (not all) of the prompts:
* We hire mostly generalists. We have a mix of senior engineers and less senior since not all of the things people learned in the past translate to coding with LLMs. As you said, the model can fill in the details. 10x engineers definitely exist, and they often span across multiple areas — product and design, product and business, product and infra.
* Pretty much 100% of our code is written by Claude Code + Opus 4.5. For me personally it has been 100% for two+ months now, I don’t even make small edits by hand. I shipped 22 PRs yesterday and 27 the day before, each one 100% written by Claude. Some were written from a CLI, some from the iOS app; others on the team code largely with the Claude Code app Slack or with the Desktop app. I think most of the industry will see similar stats in the coming months — it will take more time for some vs others. We will then start seeing similar stats for non-coding computer work also.
* The code quality problems you listed are real: the model over-complicates things, it leaves dead code around, it doesn’t like to refactor when it should. These will continue improve as the model improves, and our code quality bar will go up even more as a result. My bet is that there will be no slopcopolypse because the model will become better at writing less sloppy code and at fixing existing code issues; I think 4.5 is already quite good at these and it will continue to get better. In the meantime, what helps is also having the model code review its code using a fresh context window; at Anthropic we use claude -p for this on every PR and it catches and fixes many issues.The Missing Primitives of Agent Infrastructure
看了我自己的理解是AI infra 这块包括基础软件的发展，会有些不一样，都会有些新的要求，比如：向量数据库、计算层和硬件的管理等等。
好长，Gemini 可以总结，放个最后的片段，活力枯竭，希望不要有那么一天，虽然现在趋势是这样，我们的韧性是不是还在，不知道，不过我感觉自己还是悲观的一派。
Dan Wang 在 2025 年信中传达了一个明确的信息：中美两国的轨迹正在发生深刻的背离。 中国正在变成一个高效但孤独的工业堡垒，面临着严重的社会活力枯竭；而美国虽然体制混乱、问题重重，却意外地在一片混沌中点燃了 AI 和能源革命的火种，重新夺回了“未来感”。
他的结论是：未来的竞争不仅仅是 GDP 的竞争，更是关于“哪种社会模式能让其公民对未来更有信心”的竞争。写的有点杂，对于 Plan 模式，到底有没有必要，包括 SDD 这一块，有不同观点，自己尝试最重要，不过作者提到的 AI 组织方式其实是一个未来持久的话题，看到的是还在分工角色，但是从 Builder 这个角度真有必要吗？
这个文章有些不同的观点
AI时代更好的组织架构，分享一下 AI 软件开发的流程：
* 产品经理先画草图
* 产品经理和技术总监和项目经理沟通需求
* 技术总监研究出每个地方核心点的技术原理
* 打开 Claude Code Opus，进入 plan 模式，先告诉 AI 你要做什么软件，然后告诉 AI 每个点的核心技术，然后产品经理详细描述一下软件的 PC 和手机的控件细节和交互流程
* 让 AI 总结软件的实现细节、核心原理、交互流程，并且让 AI 检查逻辑操作漏洞和交互细节，反复检查
* 没问题后让 AI 干活，30 分钟左右全自动干完
* 测试，让 AI 改界面，改逻辑，改 UI 细节
* 开发对接懒猫微服存储
* 发布，给用户反馈，让 AI 修 bug20260120 B 站直播 —— 转行大模型文字精要 | 木鸟杂记
当下转行大模型是好多技术人的想法，包括我自己，这是未来的科技趋势，只有走在准确的科技趋势上才能吃到科技带给自己的红利，文章谈了一下如何转向，不同方向和目前的趋势，列出的参考也是蛮值得学习深入的，转向需要深入，而不是泛泛而，懂个概念就可以了，同时知道自己需要啥，明确方向才能有的放矢努力向前。
