How-and-What-Im-Building-This-Week 解读

背景

• 文章标题：How (and what) I'm building this week
• 来源：https://www.bensbites.com/p/how-and-what-im-building-this-week
• 作者：Ben Tossell（Ben's Bites）
• 定位：这不是一篇严格的技术论文，也不是单一工具测评，而是一篇 AI Builder 工作流周记 / 工具栈公开笔记。

这篇文章最有价值的，不是某个单独工具，而是作者把自己一周的 Agent 使用习惯、工具选择、工作循环、AGENTS.md 约束 全部摊开了。

---

⚡ TL;DR / 快速结论

如果一句话总结：

这篇文章值得看的不是“Ben 用了哪些工具”，而是他已经开始把“和 Agent 协作”当成一套可复制的生产流程来设计。

我对它的快速判断

• 核心价值：把 AI 编程从“随手对话”升级成“可复用 builder workflow”。
• 最值得抄的部分：/spec/、progress.md、浏览器自检、docs-first、技能化（skills）这几个习惯。
• 最不值得照抄的部分：作者个人工具偏好、模型偏好、给 agent 开高权限这类做法。
• 文章性质：更像实践手记 + 方法论草稿，不是严谨 benchmark。

最值得你关注的 3 点

1. Agent 要有工作循环，不只是 prompt。
2. Skills / AGENTS.md / progress.md 这些“外部脚手架”会显著提升稳定性。
3. 浏览器自检 + 文档优先 + 测试覆盖，是把 vibe coding 拉回工程化的关键。

---

文章到底在讲什么

文章本质上分成 5 块：

1. 他在做一个“交互式 cookbook”

作者不想只写一份枯燥教程，而是想做成：

• 你把说明 URL 丢给 Agent
• Agent 一边带你做项目
• 你一边学概念、一边产出站点

这其实是个很重要的转向：

不是“给人看教程”，而是“给 Agent 看教程，再让 Agent 带人做”。

这非常符合未来知识产品的一个方向：

• 文档给 Agent 读
• Agent 作为交互式老师
• 用户通过 build 来学习

---

2. 他把“可视化能力”做成 skill

作者提到 Claude 新出的可视化能力后，他去逆向出一个通用 skill，让其他 agent 也能装。

这说明一个趋势：

能力开始从“模型内建功能”转向“可移植 skill / prompt / tool 资产”。

也就是说，未来你不一定关心某模型天生会不会某件事，而更关心：

• 有没有 skill 能补上
• skill 能不能迁移到其他 agent
• 能不能形成团队内部的能力包

这点对你很有启发，因为你本身就在关注：

• Obsidian 工作流
• Agent 的知识管理
• 代码理解和结构可视化

---

3. 他公开了自己的工具栈

作者把自己的工具分成几层：

模型偏好

• GPT 5.4 XHigh：偏“真正写代码”
• Opus 4.6：偏 planning / research / design

CLI / Terminal 工具

• Droid
• Pi
• Cmux
• Zed

Agent App

• Codex app
• Claude Code / Cowork
• T3 Code

Skills

• frontend-design
• json-render
• agent-browser
• react-doctor

其他基础设施 / 部署工具

• exe
• here.now
• Vercel
• gists.sh

文章不是在做硬核对比，而是在表达：

Agent 开发已经不是“一个模型 + 一个编辑器”了，而是一整套多层协作工具链。

---

4. 最关键：他的 AGENTS.md 工作循环

这篇文章最值得抄的，其实是最后这段构建 loop。

作者要求任意 agent 都遵守：

• 建 /spec/ 文件夹
• 规格文档按编号排（如 00_spec1.md）
• 建 progress.md 记录进度
• 在把链接发给人之前，用浏览器工具先 dogfood 一轮
• 写测试
• 尽量用 best practice，避免 anti-pattern
• 使用依赖/库时优先查官方文档
• 用一句固定开场白确认 AGENTS.md 已加载

这段内容的价值非常高，因为它说明：

真正稳定的 Agent 协作，靠的不是一次 prompt，而是“项目级约束 + 循环检查 + 状态记录”。

这和普通用户的用法区别很大：

• 普通用户：想到啥说啥
• 熟练 builder：先搭脚手架，再让 agent 按流程跑

---

5. 他也提到了 prompt injection / skill 风险

作者承认：

• skill prompt injection 是可能的
• 但他建议用可信来源，或让 agent 自己复查安全问题

这块思路方向是对的，但比较轻描淡写。 真实风险里还包括：

• 第三方 skill 带来的上下文污染
• 不安全工具默认开高权限
• agent 自动执行部署/浏览器/命令时的越权问题

所以这篇文章在安全上给的是“提醒”，不是成熟方案。

---

这篇文章最值得学的 6 个点

1. 把 Agent 使用方式流程化

不是每次重新想 prompt，而是固定工作循环。

2. 把知识产品改造成“Agent 可读”

这对未来教程、文档、课程形式都很关键。

3. Skills 是重要资产

不是“某个模型厉害”，而是“你手里有没有一组能力包”。

4. 浏览器自检是很实用的 agent QA 手段

在把链接给人之前先让 agent 自己看一轮站点，这个很值。

5. docs-first 是必须的

这点特别重要。Agent 太容易凭旧知识乱写，显式要求查官方文档很有必要。

6. progress.md 很实用

一旦长上下文压缩、切会话、换模型，progress.md 这种状态文件会非常值钱。

---

这篇文章的问题 / 局限

1. 偏个人经验，不是系统评测

它更像“我最近怎么用”，不是严谨实验。

2. 工具偏好有明显主观性

例如哪个更好、哪个体验顺手，这些都带强烈个人风格。

3. 默认高权限的建议要谨慎

像 Full Access / Bypass permissions 这种建议，不适合作为通用最佳实践。

4. 安全部分提得不够深入

提到了 skill injection，但没有展开完整治理策略。

5. 对团队协作还停留在个人 builder 视角

更像单兵 workflow，而不是多角色协作体系。

---

对你最有价值的部分

如果结合你现在关心的方向，我觉得这篇文章最值得你抄的是：

A. 给每个 Agent 项目固定一个脚手架

建议最少有：

• /spec/
• progress.md
• AGENTS.md
• references/（外部资料）
• scratch/（实验）

B. 给 Agent 增加“交付前自检”环节

比如：

• 代码跑没跑起来
• 页面能不能打开
• 控制台有没有错
• 关键路径能不能点通

C. 强制 docs-first

特别适合：

• Lua LSP
• Obsidian 插件开发
• 新框架接入

D. 把可视化能力模块化

你后面做知识图谱、架构图、代码结构图时，可以把“可视化输出”单独做成 skill 或模板。

---

可执行建议

如果把这篇文章变成你自己的工作流，我建议你直接落这 5 条：

1. 任何 agent 项目默认创建 /spec/ 和 progress.md
2. 交付前必须跑一轮浏览器/界面自检
3. 新依赖默认先查官方文档，再让 agent 写代码
4. 把常用能力做成 skill / 模板，而不是每次重写 prompt
5. 把阶段性总结发回聊天，而不是只藏在文件里

---

踩坑总结

问题	原因	结论 / 建议
工具列表很多，容易看花	文章是工作流周记，不是体系教程	重点看方法论，不要沉迷工具名
模型/工具偏好看起来像结论	作者在讲个人实践，不是 benchmark	抄流程，不要照抄偏好
给 agent 高权限很诱人	为了减少中断和提升效率	只有在可控项目里才考虑，默认别放太开
skills 看起来像万能解法	skill 只是能力封装，不是质量保证	需要来源审查 + 安全复核
AGENTS.md 容易写成口号	没有配合状态文件和检查循环	必须和 /spec/、progress.md、自检工具一起用

---

最后结论

这篇文章不是那种“技术深度爆表”的内容。 它真正厉害的地方是：

它把 AI Builder 的个人经验，慢慢固化成一套可复制、可迁移、可复用的协作流程。

所以它对你的价值，不在于“Ben 用了什么工具”，而在于：

• 如何把 Agent 工作流结构化
• 如何让知识材料变成 Agent 可执行输入
• 如何用 AGENTS.md / progress.md / browser dogfood 把 vibe coding 拉回工程化

如果你让我给它一句评价：

这是一篇很有用的 AI Builder workflow 手记，方法论价值高于工具情报价值。