我的 AI Coding 工作流：从Context、Skills 到 Automation

一开始，我只是用 AI 查 API、解释报错、生成代码片段。后来，我开始把完整的研发任务交给 Agent：让它读取项目、调查调用链、修改代码、运行验证，再根据结果继续推进。

这时我逐渐发现，真正影响结果的不是某一次提示词写得多漂亮，而是项目上下文、任务边界、工具权限和验证方式是否清楚。

这篇文章记录我目前正在形成的一套工作方式：我如何使用 Agent 工具，如何学习 Agent，如何把全局规则和项目 Skills 放进日常研发流程，以及哪些工作适合自动化。我不打算做工具测评，也不想给出一套必须照抄的标准答案，这只是现阶段的工作记录。

全文分为五部分：工具应用、Agent 学习路线、日常工作流、自动化，以及最近形成的一些判断。

我主要用它完成代码调查、实现、验证、审查、报告和自动化。

几个对我比较重要的能力：

• 直接进入项目目录，读取真实代码和规则；
• 执行 Git、测试、构建、ADB 等本地命令；
• 使用独立任务和 worktree 隔离上下文；
• 通过 Skills 固化项目工作流；
• 连接浏览器、桌面应用、文档和视觉工具；
• 保存任务历史和记忆，减少重复解释；
• 创建周期性自动化任务。

在 ChatGPT Atlas 中，Ask ChatGPT 是贴在当前网页旁边的紧凑聊天栏，可以一边浏览一边提问、起草或总结，不必离开当前标签页。打开方式是点击侧边的 Ask ChatGPT，或在新标签页直接开始聊天。它与当前页面共享浏览上下文；需要执行浏览器操作时，可以从提示框的 + 菜单进入 Agent mode。Agent mode 可以继续当前标签页中的任务，但不能在浏览器中运行代码、下载文件或安装扩展。

官方说明：Using Ask ChatGPT sidebar and ChatGPT Agent on Atlas (opens in a new window)。Atlas 的侧边聊天和桌面应用的 Companion Window 不是同一个功能；macOS 桌面应用的 Companion Window 可用 Option + Space 呼出，Windows 使用 Alt + Space，用于快速提问、上传文件或开始新对话。macOS 桌面应用说明 (opens in a new window) · Windows 桌面应用说明 (opens in a new window)

ChatGPT 桌面应用的内嵌浏览器用于在应用内浏览网页、登录、下载文件和检查页面。基本流程：

1. 在 ChatGPT 桌面应用中打开 Work 或 Codex 会话。
2. 点击工具栏的浏览器按钮，或使用快捷键：macOS Command + Shift + B，Windows Ctrl + Shift + B。
3. 让 ChatGPT 使用当前页面；出现权限提示时，先检查网站、账号和动作，再批准访问。
4. 需要多个页面时，让 ChatGPT 在同一任务中打开或切换标签页；下载文件前确认保存位置和内容。

内嵌浏览器使用自己的浏览器状态，和 Chrome 的 cookies、已登录会话、打开的标签页及扩展隔离。需要复用现有 Chrome 会话时，应使用 Codex Chrome extension。可用能力受账号、套餐和工作区设置影响。Using the built-in browser in the ChatGPT desktop app (opens in a new window)

Browser Tool 是让 ChatGPT 查看和操作内嵌浏览器页面的整体能力；Site Tools 是网页通过 WebMCP 暴露给 Agent 的特定工具。网页支持时，地址栏会出现箭头：点击可查看工具及其读写性质，使用中箭头会变蓝。Site Tools 只对提供它的当前页面生效，不会跨网站或跨标签页继承；页面关闭后也不可用。

Site Tools 可能读取当前页面状态和登录会话，也可能执行修改操作。ChatGPT 会在网站交互前请求许可，并在发送个人信息、购买、删除数据、修改权限或代发消息等敏感动作前再次确认。可以在桌面应用 Browser settings → Permissions 中关闭 Enable site tools。官方说明：Using site tools in the ChatGPT desktop app (opens in a new window)

桌面应用中，可以在会话列表对会话右键，选择 在新窗口打开，再用 macOS 或 Windows 的系统窗口排列将两个会话并排或分屏。这样适合把主任务和审查、资料或验证会话同时放在屏幕上；两个窗口仍是独立会话，不能把一个窗口的上下文自动当成另一个窗口的上下文。

ZCode 主要解决”人不在电脑前，但任务还在跑”的问题。我会用手机查看当前工作区、任务和会话，必要时继续输入或处理 Agent 的确认请求。

除了扫码连接，也可以通过 Bot Channel 从常用通讯工具进入工作区，更适合较长时间的移动访问。

远程控制提高的是可达性，不代表应该让 Agent 无限运行。长任务仍然需要明确阶段、超时边界和可恢复的中间结果。

Pi 不是 ChatGPT 应用的替代品，我主要在高风险或存在争议时使用：

• Adviser：让另一个模型独立给出第二意见；
• Committee：多个模型从不同角度交叉检查；
• Implementer：在干净 worktree 和明确文件范围内实现一个小切片。

使用 Pi 时，我会坚持几个边界：

• 第一轮独立审查尽量不把主 Agent 的结论喂给它；
• 长任务先做最小 preflight，确认模型、权限和工具链可用；
• 默认串行调用，避免供应商并发和限额问题；
• 实现任务必须限制允许修改的文件和验收条件；
• Pi 的 receipt 只是声明，主 Agent 仍要检查真实状态、diff 并重新验证。

当仓库已经建立 .codegraph/ 索引时，我会优先用 CodeGraph 查符号、调用者和调用路径。相比单纯全文搜索，它更适合回答：

• 这个方法是谁调用的；
• 一个状态如何跨层传递；
• 修改共享函数会影响哪些路径；
• 动态分发后真正落到哪个实现。

没有索引时，再退回 rg 和直接阅读代码。是否建立索引由项目决定，不强制所有仓库使用。

Flutter、Dart、Vue、Vite、React 等生态变化很快。涉及 API 语法、配置、版本迁移和库特有问题时，我会让 Agent 先查当前文档，再给方案。

这能减少一个常见问题：模型给出的答案逻辑上合理，但 API 已经改名、废弃或只适用于旧版本。

浏览器工具主要用于本地 Web 验证：

• 打开本地页面并操作真实界面；
• 共享已有登录状态；
• 检查 Console、Network 和页面元素；
• 截图验证布局和交互；
• 复现只有浏览器环境才出现的问题。

我通常优先使用 ChatGPT 应用内置 Browser；需要已有 Chrome 登录态、扩展或现有标签页时，再控制本机 Chrome。可重复回归和 CI 场景仍然应该沉淀为 Playwright 等正式测试。

Agent 还是得借助项目自己的工具形成证据：

• Git / Git worktree：版本、diff 和任务隔离；
• rg：快速搜索代码和配置；
• FVM / Flutter test / analyze：Flutter 项目验证；
• npm / pnpm / lint / typecheck / build：前端和 Node 项目验证；
• ADB：Android 真机、日志和 deeplink 验证；
• 项目 Makefile 和校验脚本：统一团队可复现的入口。

工具越接近项目真实运行方式，验证价值越高。

我不是先把资料全部读完才开始用，而是在真实任务里一点点补齐对 Agent 的理解。

从对话问答、代码生成、文档查询和错误解释开始，先建立对 Agent 能力边界的直觉。

慢慢理解 Model、Context、Agent Loop、Tool、Harness、Permission、Memory 和 Verification 这些基本组成。

学习把请求写成目标、范围、成功标准、禁止事项和验证方式，让 Agent 处理一个可以验收的工程任务。

把项目规则、真实代码、调用关系、历史决策和工具结果放在一起，理解上下文如何影响 Agent 的判断。

当一个流程重复出现，并且入口、权限和验证方式已经稳定时，再把它整理成可复用的 Skill。

从单 Agent 到工具调用、Skills、多 Agent 独立审查，再到有边界的自动化，一层层增加复杂度。

早期使用 AI，更多是问语法、查资料、生成代码片段。现在我更常把一个完整但有边界的任务交给 Agent，例如：

• 根据异常堆栈追踪真实调用链，定位根因；
• 修改 Flutter、Vue 或 Node 项目，并补最小必要测试；
• 审查当天提交、近 100 条提交或某个功能分支；
• 分析线上日志，输出带证据的分类报告；
• 设计发布流程、项目 Skills 和 Agent 协作契约；
• 调用浏览器、ADB、截图或本地服务验证真实行为；
• 整理文档、报告、信息图和分享材料；
• 把重复工作变成定时任务。

这里的变化是：输入不再只是”帮我写一段代码”，而是尽量包含：

目标：最终要解决什么问题
范围：允许检查和修改哪些模块
成功标准：什么结果才算完成
验证：需要运行哪些检查
边界：哪些操作不能做，哪些事实不能猜

适合了解某段代码、比较方案、查询最新文档。默认只读，不直接改代码。

适合线上日志、崩溃堆栈、网络问题和状态异常。要求沿调用链、配置链和数据流定位根因，不把报错行直接当作根因。

适合边界清楚的功能和 Bug 修复。Agent 可以修改代码，但必须控制 diff，并执行与风险匹配的验证。

重点找运行时缺陷、行为回归、边界遗漏和验证缺口。审查阶段默认只读，避免一边改一边改变证据现场。

适合固定周期、规则稳定、输出可检查的工作。目前我会把每日提交审查、每周代码健康检查、周报和已完成 Spec 归档等任务交给自动化执行。

存放跨项目长期有效的偏好，例如：

• 默认中文、结论先行；
• 修改前先理解调用关系；
• 保留用户已有改动；
• 不擅自 commit、push 或执行破坏性命令；
• 没有验证证据就不能声称成功；
• 涉及开源库最新 API 时查询当前文档。

这相当于给所有 Agent 设置一套最低工程标准。

项目层描述真实的工程约束，例如：

• 项目结构、模块边界和代码风格；
• Flutter、Vue、后端各自的验证命令；
• 哪些目录可以修改；
• Spec、实现、审查、归档怎样衔接；
• 项目特有的业务规则和例外。

项目规则应该跟着仓库走，避免团队流程依赖某个人电脑上的全局配置。

任务层只描述这次工作的目标、范围和验收标准。越接近当前任务的明确规则，优先级越高。

这条流程不是要求每个小改动都写一套文档，简单、低风险、可回滚的任务直接完成即可，只有复杂或高影响任务才进入 Spec / Plan。

复杂需求最容易出现的问题，是 Agent 在需求仍然模糊时就开始写代码。我的做法是先把下面几件事说清楚：

• 用户真正想解决的问题是什么；
• 哪些行为必须保持不变；
• 影响哪些模块、接口和状态；
• 验收条件如何映射到测试或可观察结果；
• 哪些风险需要提前验证。

然后再拆成尽量独立的垂直切片。每个切片都应该能说明：改了什么、为什么、怎么验证、还缺什么。

报错堆栈、日志和用户描述通常只是症状。真正修改前，我会要求 Agent：

1. 找到入口和直接调用者；
2. 追踪状态、配置或数据从哪里产生；
3. 检查相邻调用路径是否也受影响；
4. 找到所有路径共同经过的最小修复点；
5. 留下一个能防止回归的最小验证。

一个共享入口上的正确保护，通常比在多个页面分别加判断更小、更可靠。

我通常看四类证据：

• 静态证据：代码、调用关系、配置、Git diff；
• 自动检查：单元测试、Widget 测试、静态分析、lint、构建；
• 运行时证据：日志、接口响应、浏览器、真机、ADB；
• 外部结果：CI、后端联调、应用商店、生产环境。

这些层级不能互相冒充。比如本地测试通过，不等于线上、CI 或应用商店已经验收；另一个模型说”没问题”，也不等于真实 diff 和测试没有问题。

复杂功能、并行任务和外部 Agent 实现，尽量放到独立 worktree：

• 每个任务有独立文件状态；
• 主工作区已有修改不会被覆盖；
• 可以清楚检查每个 Agent 的实际 diff；
• 失败任务可以保留现场，不污染主分支。

但 worktree 只隔离文件，不会自动解决共享设计冲突。多个 Agent 同时修改依赖注入、公共配置或共享类型，仍然应该串行处理。

AGENTS.md 适合放原则，Skill 适合放一个具体任务的操作手册。

我现在更关注 Skill 的触发条件、输入输出契约、权限边界和失败处理，而不只是里面写了多少提示词。

全局 Skills 不绑定某个仓库，适合跨项目复用：

这些能力的组合通常是：find-docs 负责官方技术资料，tavily-* 负责外部研究，prompt-optimizer 负责把任务写清楚，pi-agent 或 claude-coder 负责独立执行，handoff 负责跨会话交接，主 Agent 最后负责证据核对。

项目 Skills 绑定业务应用的目录、架构和验证规则，是真正进入业务代码时的主流程：

项目内还有一个重要设计：Skill 不只是”提示词合集”，而是带有入口检查、允许修改范围、验证命令、输出格式和失败处理的操作契约。

wayfinding
  -> grilling
  -> examine-architecture / domain-modeling
  -> to-spec
  -> implement
  -> test + simplify
  -> code-review
  -> archive-specs

如果需求还没有收敛，不直接进入 to-spec；如果只是一个很小、低风险的修改，也不强行走完整链路。

wayfinding -> grilling -> create-page
           -> app-components
           -> test（仅在存在关键交互或状态逻辑时）
           -> simplify -> code-review

页面 Skill 负责结构和入口，组件 Skill 负责复用视觉能力，测试和审查负责行为证据。

wayfinding -> grilling -> create-api
           -> test（Model / Repository / 关键映射）
           -> simplify -> code-review

接口变更先确认真实 API 契约和现有 DkHttpClient/Repository 模式，再生成 Model，避免只根据一段示例 JSON 编代码。

wayfinding -> debug -> test（先复现或补最小回归）
           -> implement（若需要跨文件修改）
           -> simplify -> code-review

debug 负责找到根因，implement 负责按边界落地；不能把”排查”和”顺手重构整个模块”混成一件事。

主 Agent 调查
  -> pi-agent adviser / committee（独立意见）
  -> 主 Agent 决策
  -> implement 或受限 pi-agent implementer
  -> 主 Agent 重新检查 diff 与验证

全局 Skill 负责外部协作，项目 Skill 负责业务实现。两者组合时，项目规则仍然是代码修改的最终边界。

不用一开始就搭建完整体系，可以先从一个小闭环开始：

1. 写一份简短的项目 AGENTS.md，只放真实且长期有效的规则；
2. 选择一个低风险 Bug，让 Agent 先调查调用链，再做最小修改；
3. 明确要求它运行一个能证明行为的检查；
4. 自己检查最终 diff，不以 Agent 的总结代替代码；
5. 把重复出现三次以上的稳定流程，再整理成 Skill 或自动化。

先把一个可靠闭环跑通，再考虑浏览器、CodeGraph、多 Agent、记忆和自动化。工具可以慢慢加，验证边界要从第一天就定下来。

我只把重复、规则稳定、结果能检查的工作交给自动化。提交审查、周报和归档符合这几个条件；需求取舍、生产发布、删除数据和高风险代码修改不应该默认无人值守。

每个自动化都应该留下时间窗口、实际范围、执行命令、输出结果、失败原因和未覆盖项。没有这些字段，定时任务只是定时生成一段看起来合理的文字。

我把自动化拆成三个维度：

• 触发：什么时候运行，按本地时间还是云端时间；
• 执行：在哪个项目、哪个 worktree、用什么模型和权限运行；
• 输出：结果写到哪里、是否通知、失败时如何报告。

本地自动化可以读取本机仓库和工具，但会受到电脑开机、权限、网络、依赖和服务状态影响。云端自动化不依赖本机是否开机，更适合提醒、资料整理和周期性汇总，但通常不能直接读取本地未提交代码或本地登录态。

这几项任务都按同一套做法运行：先限定范围，再读证据，只执行被授权的动作，最后写清结果和 coverage gap。自动化显示成功，只能说明这次任务按规则跑完，不代表项目没有风险。

以下为当前本机自动化实际使用的提示词（不含”周报总结”）。

在 `/Users/xxx/xxx` 审查当天 00:00:00（Asia/Shanghai）至运行时刻、所有本地可见 refs 上的已提交变更；按 SHA 去重，统一审查，不按 branch 分组。无提交则直接输出"无变更"。

先读 `AGENTS.md` 和 `docs/skills/skill-context.md`，遵守其中的范围/证据规则，但以本任务目标和输出契约为准。只读变更文件、直接调用方/被调用方、相关类型和已有测试，不扩展为全仓库审查。

重点检查运行时风险：Widget 生命周期与 dispose 后回调、异步竞态和 await 后 BuildContext、Timer/Stream/Controller/监听器释放、状态 owner/缓存/UI 不同步、空值/默认值/序列化/接口兼容、重复导航/错误恢复/请求幂等、iOS/Android/Web 分支和路径差异。每个 finding 必须有文件位置、可达调用路径、失败场景、影响和代码/测试证据。排除纯风格、lint 可直接发现、无具体失败场景的猜测；不因缺少测试单独立项。

只在与变更直接相关时运行 targeted tests；不运行全量测试、`flutter analyze` 或架构守卫。严禁修改、格式化、生成、暂存、提交或推送文件。

固定输出：`result`、`scope`、`findings`（仅有问题时）、`verification`、`coverage_gap`。

在 `/Users/xxx/xxx` 的独立 worktree 中，审查当前作者过去 7 天内 HEAD 可达的重大代码提交，识别代码健康、架构偏移、模块边界侵蚀、重复实现、状态/数据流复杂化、测试策略缺口和高风险设计。每日近 24 小时运行时检查负责缺陷发现，本任务不重复它，也不读取其 memory。

只以当前仓库状态和本次命令输出为事实；不修改、格式化、生成、暂存、提交或推送文件。先读 `AGENTS.md`、`docs/skills/skill-context.md`、`.agents/skills/debug/SKILL.md`。通过 `git config user.name/email` 获取作者；缺少则报告 blocker，不猜测。无符合条件的提交则输出无近期作者提交。

按提交规模、跨模块影响、公共 API/类型、状态所有权、数据流、构建/发布路径、平台分支、依赖和测试策略筛选重大提交，快速排除纯文档/配置微调/局部低风险修复。只读候选提交、变更文件、直接调用方/被调用方、相关类型、spec、测试和必要架构文档，不扩展为全仓库审查。

每个问题必须有文件位置、提交/diff 证据、可达调用/状态/数据流、风险场景、影响，以及根因层面的最小解决方案、验证计划和迁移/兼容风险。排除纯风格、无具体失败/演进场景的猜测、lint 可直接发现的问题；测试缺口仅在会掩盖具体高风险变化时报告。仅运行只读或不改变工作区的最小必要命令，并在前后记录工作区状态。

发现问题时输出 `result`、`scope`、`findings`、最多 3 个 `excluded_candidates`、`verification`、`coverage_gap`；无问题时输出 `result`、`scope`、最多 3 个 `checked_candidates`、`other_candidates`、`verification`、`coverage_gap`。无缺口写 `none`。

扫描当前仓库 `docs/tasks/`，使用 `archive-specs` skill 归档已经实现且有验证证据的任务。

先读 `.agents/skills/archive-specs/SKILL.md`。仅处理具备 `SPEC.md`+`PLAN.md`（或 skill 允许的 legacy 输入）、代码已实现且有测试/review/git/doc 证据的任务。方案阶段、实现不完整、验证失败、关键证据缺失或 ownership 不明的任务列入 `skipped`，说明原因。

超过 30 天的任务必须判定状态，但不得仅按年龄归档、删除或标记 implemented。年龄优先取目录名 `YYYY-MM-DD`，否则取 `createdDate` 或首次 Git 提交时间，并说明依据；状态仅可为已实现、进行中、已取消或已被替代。无法可靠判定的列入 `stale_tasks`，写明年龄、已查证据、缺失信息和建议动作。

归档前检视实际代码和证据。按需写入/更新 `docs/archived-specs/` 模块级 implemented living spec、`docs/api/` 和 README；不要删除、移动或重命名 `docs/tasks/<date>-<name>/`，只提示后续可清理的目录。未提交变更可作为判断依据，但必须说明涉及文件。

固定输出：`archived`、`skipped`、`stale_tasks`（无则 `none`）、`verification.executed`、`verification.evidence_read`、`follow_up`（无则 `none`）。

这两个任务运行在 ChatGPT Web 的云端”已安排”列表中，不依赖本机是否开机，也不读取本地未提交代码。它们更像”定期研究 + 产出 + 发布”的远端 Agent，而不是本地代码检查脚本。

• 频率：每周一上午；当前页面显示下次运行时间为 4 天后。
• 目标：汇总过去一周真正影响工程决策的前端和移动端进展，并准备发布到 https://github.com/calvingit/blog。
• 覆盖：React、Vue、Node、构建工具、UI 生态、代码质量工具，以及 Flutter、iOS、Android、React Native。
• 信息优先级：官方文档、Release Notes、官方博客和 GitHub 一手记录优先；社区内容只用于发现线索，必须二次验证。
• 输出：中文技术分析，说明影响范围、破坏性变更、迁移成本、对现有项目的实际影响和行动建议。

• 频率：每周五下午；当前页面显示下次运行时间为明天。
• 目标：生成面向资深工程师的 AI 软件工程分析文章。
• 核心视角：不按新闻时间线罗列事件，而是先提出本周工程判断，再用事实支撑判断。
• 关注范围：Coding Agent、Agent Runtime、planning/delegation/multi-agent、Skills/Rules、MCP、权限与安全、Worktree、评测、可观测性和 AI Developer Infrastructure。
• 证据要求：区分已验证事实、来源观点和工程分析；优先使用官方文档、源码、Release Notes、论文和 benchmark；社区内容不能作为唯一事实依据。
• 文章要求：讨论为什么成立、可能被高估的地方、限制和反方观点；外部事实使用 Astro/MDX footnote，并集中定义参考资料。
• 提示词：

每周生成一份 **AI Software Engineering Weekly**。

面向有经验的软件工程师，分析过去一周真正影响软件工程决策的 AI 变化。不要按厂商或时间线罗列新闻，先提炼工程判断，再用证据支撑；没有足够重要的主题时可以少写，不要为了周更制造趋势。

要求：

- 区分已验证事实、来源观点和工程分析，不把推断写成事实。
- 优先使用官方文档、Release Notes、源码、论文和 benchmark；社区内容只用于发现线索，事实需继续追溯。
- 对每个判断检查反例、技术限制、成本、维护负担，以及是否值得普通团队现在投入。
- 重点关注 Coding Agent、Agent Runtime、Planning/Delegation/Multi-agent、Skills/Rules、MCP、权限与安全、Worktree/Sandbox、评测、可观测性、可靠性，以及 AI 对开发、测试、审查和 CI/CD 的影响。
- 文章使用中文，说明变化是什么、为什么重要、适用边界、反方观点和行动建议；外部事实用 Astro/MDX footnote，并集中整理参考资料。

信息来源优先级：官方一手资料 > 论文与 benchmark > 高质量工程实践 > 社区信号。每期只选择少量有工程价值的内容。

固定输出：本期判断、证据与链接、限制和反方观点、对工程团队的影响、行动建议、未验证项。

这两个云端任务的共同点是：长期运行、持续研究、先做判断、保留来源、再生成对外内容；它们和本机自动化的区别在于，本机任务有文件系统和项目命令访问能力，云端任务更适合周期性信息生产与远端协作。

稳定效果通常来自项目规则、真实代码、调用关系、历史决策、验收标准和工具权限。只改一条 prompt，补不上缺失的上下文。

多个 Agent 同意，并不天然代表结论正确。如果它们共享了同一份错误前提，只会更一致地犯错。

多 Agent 更适合：

• 独立调查后交叉验证；
• 按文件或垂直切片隔离实现；
• 让实现者、验证者和审查者承担不同角色。

不适合让多个 Agent 同时修改公共配置、共享类型或同一条核心调用链。

我会自动化重复、规则明确、结果可检查的任务，例如每日提交审查和每周健康检查；不会把需求决策、生产操作或高风险发布默认交给无人值守任务。

自动化要留下：执行范围、时间窗口、真实输出、失败原因和未覆盖项。没有这些，自动化只是定时生成一段文字。

长期记忆适合记录稳定的项目约定、已经验证的命令和容易重复踩坑的边界。对版本、分支、服务状态和外部接口等易变化信息，仍然需要现场复查。

最小改动要建立在充分理解之上。为了让 diff 看起来小而跳过调用链调查，通常只是把第二个 Bug 留给以后。

我理想中的 Agent 是：先把问题看完整，再用最少的代码解决它。

Agent 可以调查、修改、验证和汇报，但需求取舍、风险接受、生产操作和对外承诺仍然需要人负责。

我不追求”完全无人参与”。我更希望把人的注意力从重复操作移到：

• 目标是否正确；
• 证据是否充分；
• 风险是否可以接受；
• 这个改动是否真的值得存在。

这份清单来自最近一个月的 Chrome 历史和收藏标签，建议按”先理解运行机制，再接入工具”的顺序阅读。

半年时间关注了 349 个仓库， 当然大部分是吃灰的，只是方便自己搜索。下面只补充与 Agent 工程学习直接相关、且能补足现有资料的项目。

• AI Agents in Depth：基础与工具 (opens in a new window)：理解 Agent Loop、Harness、Tool、Context 和 Permission。
• AI Agents in Depth：MCP (opens in a new window)：了解模型如何连接浏览器、文件和业务系统。
• π-agent book (opens in a new window) / PI from Scratch (opens in a new window)：从运行时和最小实现角度拆解 Coding Agent。
• Inside DeepSeek Harness (opens in a new window)：观察上下文、工具和长任务控制如何组织。
• earendil-works/pi (opens in a new window) / apache/maka (opens in a new window)：对照会话、工具结果、权限和终止事件的真实实现。

• Skills For Real Engineers (opens in a new window) ：相比于 Superpowers，更加接地气的skills工程，App 的工作流借鉴很多
• calvingit/pi-skills (opens in a new window)：参考 adviser、committee、implementer、heartbeat 和 worktree 约束。
• incremental-implementation (opens in a new window)：把大任务拆成可独立验证的小步。
• reclaim-code-entropy (opens in a new window)：理解”简化代码”必须以行为证据为前提。

• CLIProxyAPI (opens in a new window) / Codex Provider (opens in a new window)：研究多模型、账号和兼容接口的统一接入。
• QuantumNous/new-api (opens in a new window)：了解模型聚合、协议转换、密钥和用量管理。
• ChatGPT Work and Codex (opens in a new window)：确认 ChatGPT 应用及编码模式的当前产品边界。

• Chrome DevTools MCP (opens in a new window)：把 DOM、Console、Network 和性能检查交给 Agent。
• ZCode (opens in a new window) / Subagents (opens in a new window)：观察远程工作区和子 Agent 协作。
• VelaTerm (opens in a new window) / ego lite (opens in a new window)：对照终端工作区与浏览器型 Agent 的交互方式。

这段时间用下来，我对 AI Coding 的理解是：

模型决定能力上限，工作流决定结果下限。

模型会继续变强，工具也会不断变化。对我来说，项目上下文、任务边界、工程验证和人的判断，仍然是这套工作方式里不能省掉的部分。 写代码变快以后，真正需要花时间的，反而是想清楚要做什么，以及怎么判断它做对了。