AI 学习方法、求职与认知升级
新资料让这页不只停留在“多看少看项目”的层面，而是进一步把学习对象扩展到 Agent 原理、Harness、Skill 设计与工作流治理。现在真正拉开差距的，不只是会不会用工具，而是能不能理解工具背后的结构。 [[raw/2026-04-05/问答/为什么你学了 100 个项目，不如别人学 10 个.md|来源: 为什么你学了 100 个项目，不如别人学 10 个.md]] [[raw/2026-04-27/小傅哥/《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md|来源: 《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md]]
学习方法：从收藏转向结构
- “学 100 个项目不如学 10 个”的老问题还在，但现在多了一层：如果不理解 agent loop、context engineering、skill trigger 和 harness，资料再多也只会越攒越乱。 [[raw/2026-04-05/问答/为什么你学了 100 个项目，不如别人学 10 个.md|来源: 为什么你学了 100 个项目，不如别人学 10 个.md]] [[raw/2026-04-28/侑夕/你不知道的 Agent：原理、架构与工程实践.md|来源: 你不知道的 Agent：原理、架构与工程实践.md]]
- 小傅哥的智能体入门文把历史、用途、框架和生态拉平了，适合给“刚被一堆新名词拍脸”的人搭底层地图。 [[raw/2026-04-27/小傅哥/《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md|来源: 《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md]]
工作流认知：别把自动化当终点
- “AI 工作流最重要的不是更自动化，而是不打断人” 这个观点很值得补进来：一个足够轻、足够不断流的系统，比极度炫技但天天打断人的全自动流程更容易活下来。 [[raw/2026-04-30/问答/AI 工作流最重要的不是更自动化，而是不打断人.md|来源: AI 工作流最重要的不是更自动化，而是不打断人.md]]
- 这也解释了为什么越来越多实践在强调 Skills、Harness、OPC 和治理框架：它们不是炫技，而是在减少”中断成本”。 [[raw/2026-04-27/青斧/工作流的 Skill 怎么写？从 7 个顶级 Skill 中提炼的模式与最佳实践.md|来源: 工作流的 Skill 怎么写？从 7 个顶级 Skill 中提炼的模式与最佳实践.md]] [[raw/2026-04-26/宇宙编辑部/YC 合伙人：如何利用 AI，从零建立一家出色的 OPC.md|来源: YC 合伙人：如何利用 AI，从零建立一家出色的 OPC.md]]
- 但流程设计本身可能成为陷阱。”反傻瓜流程”（anti-fool process）问题：企业合规流程主动抵消 AI 的效率增益——“AI 5 分钟写完代码，但要过 7 道审批流程花 5 天”。流程本是为防止犯错而设计，但在 AI 时代变成了防止提速的枷锁。 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]]
- AI Loop 悖论：AI 跑目标导向循环（goal-oriented loops）让自己变强，而人类跑流程导向循环（process-oriented loops：周会→需求评审→技术评审→测试评审→发布评审→复盘）让自己更累。循环在消耗人，而不是人在利用循环。 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]]
- 另一个隐藏问题：平行宇宙——技术团队 AI 采纳率冲到 80%，业务团队仍是 0%。工具由技术人员为技术人员打造，从未真正触达实际瓶颈所在的业务侧。 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]]
AI 认知悖论（2026-05 新增）
AI 用得好不好，跟工具几乎没关系。两块认知决定效率：对事情本身的认知（你知不知道这活怎么干）+ 对 AI 能力的认知（你知不知道 AI 有什么能力怎么组合）。AI 越强，对人的要求反而越高。
“AI 既增加了对判断力的需求，同时也在侵蚀孕育判断力的经验土壤。“真正会写报告的人知道哪句话该放前面、哪个数据该突出——这些判断力是亲手写出来、被骂过、改过三遍才长出来的。AI 帮你跳过了过程，也跳过了成长。[[raw/2026-05-12/金先森是朝鲜族阿/Claude和GPT全买了，AI用起来为啥还是不好用？老金来告你！.md|来源: AI 认知悖论]]
AI 认知四层金字塔：对话与生成 → 工具调用（MCP/RAG）→ 技能与扩展（Skills/Plugins）→ 自主执行（Agent Mode/Computer Use/Multi-Agent）。每升一层，效率翻一个量级。
这个悖论有深层原因：AI 缺乏真正的经验。AI 只有人类经验的合集——它知道”逻辑上可行的路”，但不知道”现实中能走的路”，这两条路可能完全无关。就像搬过家才知道要提前收拾，AI 可以告诉你搬家流程，但不能替你感受”提前收拾”的必要性。AI 没有”偏见”（即人类基于经验的判断倾向），这是它做判断时的根本劣势——它可以提出无数选项，但不知道哪个是对的。 [[raw/2026-06-20/云舒的AI实践笔记/AI用的越多，越觉得人的判断重要.md|来源: 云舒-AI判断]]
矛盾：通过充分的上文工程（Context Engineering）和管理，Agent 可以完成大部分编码任务 vs 云舒认为复杂架构设计和高吞吐量数据库设计必须人先想清楚，AI 可以给方案但人必须做选择，“AI 没有真正的经验”是根本原因 来自 [[raw/2026-06-20/云舒的AI实践笔记/AI用的越多，越觉得人的判断重要.md|来源: 云舒-AI判断]] 矛盾：AI 生成内容的瓶颈在于上下文不足，补充足够上下文即可 vs 云舒认为根本原因不在上下文不足，而在于 AI 没有真实的个人经验，无法从”做过”中获得判断力 来自 [[raw/2026-06-20/云舒的AI实践笔记/AI用的越多，越觉得人的判断重要.md|来源: 云舒-AI判断]]
编码任务的可自动化分界线（2026-06 更新）：
- 可全自动化/托管：需求复杂度不高、无架构决策的简单编码任务（如加 Token 消耗统计+定时任务）
- 必须人先决策：架构设计、提示词设计、高并发/高吞吐量系统设计——人必须先想清楚结构和边界，再让 AI 填充实现
- AI 无法替代：选题决策（如公众号主题），因选题依赖个人真实经历和阶段性思考 [[raw/2026-06-20/云舒的AI实践笔记/AI用的越多，越觉得人的判断重要.md|来源: 云舒-AI判断]]
AI 时代面试：简历关键词 vs 真能力
2026 年面试中，“用过 AI 编码工具”和”高频重度使用者”之间的差距巨大。面试案例：5 年经验候选人简历写了 6-9 页、堆满技术栈名称，但 AI 编码能力仅 4/10，连 Cursor/Claude Code/OpenCode 的差异都说不清。
真正的 AI 编码高级能力体现在：怎么给上下文、怎么限制改动范围、怎么做工具链集成、怎么沉淀规则。 [[raw/2026-05-14/爱海贼的无处不在/最近面试了一个豪华简历5年的高级开发者，我给了他面试不通过.md|来源: 面试标准重构]]
信息差红利（2026-06 新增）
但 AI 行业存在巨大的信息不对称。叶小钗指出一个现实：多数公司分不清生产级 AI 项目和 Demo 的区别，AI 项目经历可以包装且企业没有识别能力——这对求职者是阶段性红利期。同时，企业招聘侧”觉得容易分不清好坏”，真实情况是进入门槛高但 Demo 门槛低。当前行业”及格线以上的人不占 10%”。 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: 叶小钗]]
矛盾：AI 行业门槛很高，普通求职者应该谨慎入场 vs 叶小钗认为信息差极大、鱼目混珠，现阶段进入 AI 行业有红利，企业招聘侧有很大走展空间 来自 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: 叶小钗]]
竞争力公式：竞争力 = 专业能力 x AI 工具 x 项目作品 x 知识表达。当前阶段，四项中任何一项为零结果即为零。这比单纯堆技术栈名称或 token 消耗量更全面地定义了”真能力”。 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: 叶小钗]]
AI 行业三大原生红利岗位（2026-06 新增）
叶小钗梳理出 AI 时代三种岗位融合趋势带来的红利机会：
- AI 全栈工程师：不再区分前后端和架构师，也不再区分 Java/PHP/JS 等语言，岗位融合要求一个人能端到端交付
- FDE（前端部署工程师）：现场交付复杂度高但工资高，是 AI 代码产出与生产部署之间的桥梁角色
- AI 产品经理：工作范围大幅扩大，需要理解模型能力边界、设计 prompt flow、定义评估标准 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: 叶小钗]]
矛盾：全栈工程师是 AI 时代的效率最优解（Half-Stack 反驳中的隐式前提） vs 叶小钗认为以后不再区分前后端和架构师，也不区分 Java/PHP/JS 等语言，岗位融合形成 AI 全栈工程师 来自 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: 叶小钗]]
AI 时代工程团队管理
Fiona Fung（Anthropic Claude Code 工程/产品负责人）核心判断：软件工程瓶颈从”写代码慢”转移到了验证、评审、跨职能协作和安全性。旧流程基于”写代码很贵”设计，现在”写代码几乎免费”，流程必须全部重构。
技术辩论方式从白板房画架构图，变成让 Claude 同时搓出三个 PR 直接对比代码。代码就是唯一事实来源，不是设计文档。“代码是谁写的”已失去意义——所有 PR 都有 Claude 参与。
关键警告：不应看”多少代码是 AI 写的”这种虚荣指标，关键看产品质量和可靠性。[[raw/2026-05-13/宝玉/AI 时代到底该怎么管一个工程团队.md|来源: 工程团队管理]]
Token 消耗量：AI 编程能力的硬指标
云舒提出了一个反直觉但很实用的度量标准：不以看了多少教程、收藏了多少项目来衡量 AI 编程能力，而以真实任务中消耗的 token 量为硬指标。 Token 消耗量直接反映你和 AI 协作的深度和广度——不是在”学”AI，而是在”用”AI。
数据参照：
- 日耗从春节的 1 亿 token 增长到 1-2 亿，半天就能消耗完
- 日耗 3 亿是当前个人难以突破的门槛（受模型并发限制）
协作流程演化路径：口喷需求 → PRD → notepads/todo.md → Skill 封装 → subagent 纠错 → 设计/PRD/测试前置整合模块。每一步都在把”说不清的需求”变成”结构化的工作流”。[[raw/2026-05-22/云舒的AI实践笔记/提升Coding水平就俩事：练手感，磨流程.md|来源: 云舒-练手感磨流程]]
Agent 学习路线：从概念到生产
陈思州整理了一条 8 阶段学习路线，适合系统化入门：
- Agent 概念与基础认知
- 最小 Loop：能跑起来的第一个 agent
- 工具调用 / RAG / Memory 三大基础设施
- 吃透一个现代 Harness（Claude Code / Codex / Cursor 之一）
- 多 Agent 协调与编排
- Skills 设计与协议标准化
- 浏览器操作 Agent
- 评测 / 可观测性 / 安全
贯穿原则：
- 先动手再深读：不要陷入理论学习循环
- 宁可做小的可靠 agent，不做炫 demo：可靠性 > 炫技
- 加 agent 前先加 eval：没有评估就没有方向
- 重要运行留 trace：出了问题能追溯
- 危险操作留人在 loop：不让 agent 独断专行
重要区分：“老式角色扮演多 Agent 框架”（如 AutoGen、CrewAI 的早期版本）与”现代 Agent Harness”（如 Claude Code、Codex、Cursor）的根本差异在于——前者让 agent 扮演角色聊天，后者让 agent 在工程约束下执行任务。[[raw/2026-05-21/陈思州/重磅 -完备的 AI Agent 学习路线，最详细的资源整理！.md|来源: 陈思州-Agent学习路线]]
多 Agent 协作的真相：瓶颈在结构，不在执行
孟健通过 510 个 session（15 Agent，一周）的高频词分析，揭露了多 Agent 协作的本质：
高频词：确认、BLOCKED、handoff、Kanban、review——全是交接、阻塞、验收、复盘。多 Agent 的瓶颈不在单次执行能力，而在协作结构。
关键认知：
- 下游 Agent 主动 BLOCKED 等上游 = 成熟表现，不是故障。这说明 agent 有”知道自己不知道什么”的能力
- 人类价值从”会实现”变成”会校准”：每次对 agent 输出的反馈，本质上是在标注训练样本
- 实战任务模板需要六要素：目标、输入、输出格式、验收条件、禁区、失败回调
预测新角色：“AI team manager / agent operator”——不是写代码的人，而是管理一群 agent 协作产出的人。这与上文 [[#AI 时代工程团队管理|Fiona Fung 的判断]] 形成呼应：软件工程瓶颈已从”写代码”转移到”验证、评审、协作”。[[raw/2026-05-21/孟健的AI编程认知/光会写提示词，用不好 AI Agent.md|来源: 孟健-Agent管理认知]]
JavaGuide 10 条 Vibe Coding 经验（2026-06 新增）
JavaGuide 总结的 10 条实操经验，每条都是踩坑换来的硬规则，适合作为 AI 编码新手的入门行为准则： [[raw/2026-06-01/JavaGuide/为什么同样是 Vibe Coding，别人又快又稳，你这边老翻车？.md|来源: JavaGuide 10条]]
- Git 小步提交：避免 AI 把代码改乱改坏
- 让 AI 动手前先看工作区：确认无未提交改动，单独拉分支
- 先写清目标、限制和验收标准：别丢一句”帮我实现 xxx”
- 让 AI 参考项目里的好代码：别说”写优雅点”，让它看现有代码怎么写
- 项目坑点写进规则文件：CLAUDE.md 只放 AI 容易犯错且团队必须遵守的东西
- 重复套路沉淀成 Skill：固定流程不要每次靠聊天重新提醒
- 贵模型定方向，便宜模型搬砖：强模型做 Review，便宜模型负责编码
- AI 说修好了不算：看测试、diff 和输出。高风险操作必须人工确认
- 一个会话别塞太多任务：长任务写 NOTES
- 多 Agent 先串行再并行：流程跑顺后再考虑并行
核心判断：“AI 写代码越快，Git、测试、Review、Spec 这些东西越不能丢。” [[raw/2026-06-01/JavaGuide/为什么同样是 Vibe Coding，别人又快又稳，你这边老翻车？.md|来源: JavaGuide 结论]]
AI 工具采纳陷阱：停止追逐工具，聚焦实际问题（2026-06 新增）
此前所有内容都隐含着”采纳新工具是进步”的假设。但《OpenClaw 到 Hermes》提供了一个必要的批判视角：
24 个月内出现 12 个重大 AI 工具（OpenClaw→Hermes→Claude→Codex→…），每个都声称是颠覆性的。公司全盘采用，没有一个用好，形成了一场”护城河饥荒”——每个季度的护城河在下一季度到来前就漏光了。 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]]
核心判断：AI 是工具，不是信仰。防止过时的不是追逐新工具，而是专注解决你的实际问题。
五把手术刀（Five Scalpels）：
- 停止订阅 AI 新闻——信息过载大于信息增量
- 从 OKR 中删除 AI——不要让”用 AI”本身成为目标
- 给业务团队也配备 AI 工具——技术侧的 80% 采纳率对整体无济于事
- 砍掉一半审批流程——流程是效率的最大敌人
- 接受你无法追逐每一个新工具——选择比追逐更重要 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]]
矛盾：Adopting new AI tools (Hermes, Claude Code, Codex, OpenClaw) progressively improves engineering productivity — the wiki’s entire Agent/Architecture section is built on this premise vs Tool-chasing is counterproductive — companies adopt all new tools and use none well, creating a vicious cycle where each tool is replaced before it delivers value. The real solution is to stop chasing tools and focus on concrete business problems. 来自 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]] 矛盾：AI workflow automation (Loops, Agents) is the path to higher productivity — wiki pages on Agent loops, Harness Engineering celebrate this direction vs AI Loops can create the opposite effect: AI runs goal-oriented loops and improves, while humans run process-oriented loops (meetings, approvals) and get more exhausted. The loop is writing the human, not the other way around. 来自 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes：这几个月.md]]
创业视角：AI 时代的好想法（2026-06 新增）
YC 合伙人 Jon Xu 的创业方法论提供了从”消费者”到”创造者”的认知视角转换：
完美想法不存在于抽象中——必须让想法接触现实，听客户回应。多线尝试会产生坏数据（浅反馈误导创始人）。深入一个想法应该像”穿上一层新皮肤”：改公司名、邮箱、网站、叙事，从外到内承认只服务这个问题。 [[raw/2026-06-20/Capihom/YC 合伙人：你寻找创业点子的方式不对丨Y Combinator.md|来源: YC 合伙人]]
判断创始人是否深入的标准：“我能不能运营客户的生意？“——不只是访谈 20 个老板，而是丢进一家公司就知道每天怎么出问题。客户理解和产品交付要在一个紧密循环里同时发生——边聊客户边写代码，用真实使用数据而非访谈判断需求。 [[raw/2026-06-20/Capihom/YC 合伙人：你寻找创业点子的方式不对丨Y Combinator.md|来源: YC 合伙人]]
AI 时代好 idea 的三个特征：
- 位于模型能力边缘（利用 AI 当前做不好但即将能做好的事情）
- 能 verticalize，卖结果而非软件
- 选择最有野心的版本
关键推论：软件生产成本趋近于零后，单纯做工具的价值会下降，值钱的是客户信任、牌照、监管许可和结果 ownership。AI 原生公司如果只做工具层，可能把最大经济价值留给别人。 [[raw/2026-06-20/Capihom/YC 合伙人：你寻找创业点子的方式不对丨Y Combinator.md|来源: YC 合伙人]]
矛盾：AI 创业公司可以做通用工具平台，服务多个行业 vs Jon Xu 认为 AI 时代好 idea 必须能 verticalize，最终卖的是结果而非软件，单纯做”AI 给 X 行业做软件”的价值会下降 来自 [[raw/2026-06-20/Capihom/YC 合伙人：你寻找创业点子的方式不对丨Y Combinator.md|来源: YC 合伙人]] 矛盾：多方向并行探索能降低创业风险 vs Jon Xu 认为多线尝试制造坏数据——每个方向都不够深入，拿到浅反馈会误导创始人太早放弃好 idea 来自 [[raw/2026-06-20/Capihom/YC 合伙人：你寻找创业点子的方式不对丨Y Combinator.md|来源: YC 合伙人]]
2026-07 更新：顶级用户是 Agent Manager
新资料把 AI 使用能力的上限说得更直白：顶尖 1% 用户不是会背更多工具名，而是会管理 Agent。能力包括任务设计、上下文配置、样例校准、失败模式识别、验证证据设计、预算控制和复盘沉淀。[[raw/2026-06-24/Capihom/Airtable CEO：这就是顶尖1%的人如何利用AI丨Silicon Valley Girl.md|来源: 顶尖1%用户]] [[raw/2026-06-30/ChallengeHub/Claude Code 负责人抛出新观点：AI 重写团队分工，未来最吃香的是这「五种人」.md|来源: 未来五种人]]
Junior PM 的风险不是被 AI 替代，而是跳过摩擦：PM 如果直接让 AI 生成 PRD、竞品分析和用户访谈总结，短期产出变快，长期会弱化判断力。保留抽样看原始证据、定义 good looks like、亲自校准用户问题，是防止”会产出但不会判断”的最低成本训练。[[raw/2026-06-25/Capihom/AI Agent时代，PM更要搞清楚客户到底要什么丨UserTesting.md|来源: PM 更要懂客户]]
AI Coding 能力不等于代码占比：90% AI 代码只带来约 60% 或更低的端到端吞吐提升时，说明瓶颈已经转移到需求澄清、架构决策、review、测试和流程。学习重点也应从”怎么让 AI 写更多”转向”怎么让整个系统更少返工”。[[raw/2026-06-25/郑玄/90% 的代码交给 AI 之后，字节发现了一个反常识的真相.md|来源: 字节 AI Coding 反常识]]
Code is cheap 后的学习重点：无岳的实践把这一点推得更极端：代码正在从稀缺资源变成快速生成、快速验证、快速丢弃的过程产物；真正昂贵的是读懂历史、确定边界、控制影响面、跑通验证和发布风险。工程师的学习重点因此要从”会不会让 AI 写代码”转向”会不会设计 spec、checkpoint、安全通道和最小可验证任务单元”。[[raw/2026-07-03/无岳/Code is cheap. Don’t write any.——AI Native，程序员如何提升五倍coding效率.md|来源: Code is cheap]]
反向链接
- [[wiki/concepts/Agent 原理、记忆与上下文工程]]
- [[wiki/syntheses/AI 创业与 OPC]]
- [[wiki/concepts/Obsidian、LLM Wiki 与个人知识管理]]
- [[wiki/entities/Claude Code]]
- [[wiki/concepts/Skills、Agents 与工具设计]]