导言
这份六页 PDF 与其说是“学习路线图”，不如说是一套 AI 应用工程判断法：先找到结构化、问答、摘要等能交付价值的任务；承认模型输出有波动；把真实用户反馈变成评测集；最后只在评测证明简单方案不够时，逐步增加检索、工具、工作流、Agent 或微调等复杂度。
本文逐页解释图中的观点，同时区分三件事：页面明确表达了什么、它对工程实践意味着什么、哪些口号不能按字面当成技术事实。原 PDF 没有附数据集、实验方法或参考文献，因此曲线和阶梯只能当作概念图，而不能当成性能证据。
导言
AI Coding IDE 的核心并不只是一段 system prompt。模型负责判断，Harness 负责把判断变成连续、受控、可恢复的工程过程。本文固定 Codex 与 OpenCode 源码版本，并以 Claude Code 官方行为契约为界，回答三个问题：Goal 是否只是定时任务，推理强度是否只是换 prompt，以及三种工具如何控制子 Agent 的上下文、模型与推理强度。
导言
AI 相关需求经常采用敏捷方式推进：先完成最小穿刺，遇到问题再解决问题。这种方式可以快速消除技术未知，却容易留下另一类债务：需求散落在聊天和 issue 中，关键取舍没有 ADR，安全与可靠性只在事故后出现，性能结果只有一张截图，最终很难回答“你究竟设计了什么，为什么这样设计，怎样证明它有效”。
任职要求要看的不是文档篇幅，而是从问题到结果的可复核判断链。一份合格的软件设计材料应该同时连接需求/Top 问题、架构视图、质量属性场景、候选方案、设计原则与模式、代码提交、测试/Profiling/运行证据，以及后续架构治理。缺失的环节应如实列为设计或代码工作，不能由 AI 根据最终代码补写成虚构的事前决策。
本文解释 4+1 视图、设计原则、GoF 23 个设计模式（不是 24 个）、安全威胁分析、可靠/可用性、可测试性、功能安全、体验、性能、架构治理和技术决策，并给出一个可复用的本地 Skill：输入需求和穿刺代码 commits，输出软件设计文档、任职举证报告、追踪矩阵与缺口清单。
导言
AI 技术更新很快，日常知道“最近出现了什么”并不难，真正困难的是判断：新技术到底解决了旧方案的哪个瓶颈，会替代什么、保留什么、把成本转移到哪里，以及它是否适合自己的用户、硬件和组织。
技术洞察因此不能止于论文、新闻、功能和融资信息的汇总。它要从一个具体决策出发，建立现有技术基线，读标准和代码，设计最小 Demo 与受控基准，量化瓶颈，评估技术演进、成熟度、全生命周期成本和风险，最后给出带适用边界、证据等级和退出条件的行动建议。
本文把技术全景扫描、竞品与标杆、代码与架构逆向、实验与基准、瓶颈、演进、成熟度、成本收益和风险九类方法组织成一个闭环，并沉淀为可复用的 $technology-insight Skill。
导言
需求分析报告是一份开发前的决策合同。它要在投入主要研发资源之前回答五个问题：客户真正需要什么，需求由哪些部分组成，有哪些技术路线，项目是否可行且值得做，以及每条需求究竟如何定义和验收。
即使报告是在功能已经穿刺或实现之后补写，正文也不应从“已经完成了什么”出发。代码、测试和实验只能作为分析者校验接口、约束、技术可行性和估算边界的材料；最终报告仍应冻结在开发决策时点，使用“应、必须、拟采用、计划验证”的语态，不写实现完成率、测试通过情况或上线效果。
本文按六个阶段组织完整方法：识别真实需求、拆解需求组成、调研与选择技术方案、评估可行性/工作量/价值、定义需求与验收、确定优先级并建立基线。每个阶段都明确要消除的不确定性、适用方法、输出物和评审门。
导言
我曾把一个看起来很明确的任务交给 AI：阅读 verl 代码，参考已有 GRPO 脚本适配 Kimi3 的减层训练，并在 NPU 上跑通第一个强化学习优化步。两天后，AI 仍在换软件版本、调整层数和重跑 OOM。真正棘手的不是“还没成功”，而是我无法回答领导接下来一定会问的问题：卡在哪里、解决过什么、时间花在哪里、还能不能解决、还要多久、代码是否上仓、中文设计文档在哪里？
这促使我把 Goal 从一句终点描述改造成一个工程控制面：用 goal-definition 先与用户签订任务合同，再让每个 Goal 强制携带 goal-execution，按证据等级执行有界循环。最终目标仍然重要，但每一轮都必须留下新的事实、排除一个原因，或形成一个可交付成果。
导言
单个 Codex 或 Claude Code 窗口的问题，不只是“subagent 开得少”，而是人无法稳定回答四个问题：派了谁、做到哪、交了什么、谁验收。调研后的结论是：AutoResearch 已经拥有最重也最重要的持久控制面；下一步不应重写一个多智能体平台，而应补齐人工 UAT，把 Archon 限定为可选的阶段工作流，把 Pi、Codex 和 Claude 作为可替换 worker。
导言
多局点、多任务、多角色同时推进时，真正稀缺的不是勤奋，而是 判断力、取舍能力和可复用记录。均匀响应所有任务只能保证不出明显纰漏，却很难形成个人优势；优势通常来自少数高风险、高杠杆、高不确定、强依赖的局点。
本文把工作链路整理成一个可执行系统：先识别重点风险局点，再拒绝低优先级任务；先快穿刺关键假设，再并行派活和紧跟踪；先用原理、显存、性能 MFU 和投产约束做建模，再用实践验证、详细记录和持续修正形成历史；最后把优势进展、后续风险和必要求助稳定汇报出去。
导言
这篇文章记录我当前的 Work with AI 文档工作流：不是把一段 prompt 扔给模型、得到一篇孤立文章，而是把调研、来源管理、论文图表、正文插图、图片上传、Hugo 写作规范、可复用 skill 和 git 发布串成一个可验证的流水线。
这条流水线的关键变化来自 Karpathy 的 LLM Wiki 思路：把知识库视作一个由 LLM 维护的 Markdown 代码库。原始资料进入 raw 层，结构化理解进入 wiki 层，Hugo 文章只是最终发布层。这样每次写作都会沉淀可复用记忆，而不是从聊天记录里重新发明一次。