<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xsl" href="https://www.fen9pi.cn/atom.xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="zh-CN">
  <id>https://www.fen9pi.cn/</id>
  <title>Fen9Pi的写作空间</title>
  <subtitle>把复杂东西拆明白的工程师：AI 时代的软件工程、网络与安全、Agent Skill 工程与极客硬件</subtitle>
  <updated>2026-10-14T12:20:53.006Z</updated>
  <generator>@vuepress/plugin-feed</generator>
  <link rel="self" href="https://www.fen9pi.cn/atom.xml"/>
  <link rel="alternate" href="https://www.fen9pi.cn/"/>
  <category term="随笔"/>
  <category term="AI Agent"/>
  <category term="AI 工程"/>
  <category term="方法论"/>
  <category term="开源拆解"/>
  <category term="Skill 工程"/>
  <category term="技术专题"/>
  <entry>
    <title type="text">3G资本的人才密码：为什么他们专招「穷聪明」的人</title>
    <id>https://www.fen9pi.cn/posts/3g-capital-psd/</id>
    <link href="https://www.fen9pi.cn/posts/3g-capital-psd/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1542831371-29b0f74f9713-40sbgd.jpg" alt="3G资本"></p>
<blockquote>
<p>出身贫寒、极度聪明、有强烈的致富野心。</p>
</blockquote>
<p>这三个特征组合在一起，构成了 3G 资本的用人哲学核心——<strong>PSD 型人才</strong>。</p>
<p>3G 资本，这家由三个巴西人创办的投资帝国，用这套人才策略，从一个巴西小券商起步，先后拿下了百威英博、汉堡王、卡夫亨氏、Tim Hortons，管理着超过 500 亿美元的资产。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1542831371-29b0f74f9713-40sbgd.jpg" alt="3G资本"></p>
<blockquote>
<p>出身贫寒、极度聪明、有强烈的致富野心。</p>
</blockquote>
<p>这三个特征组合在一起，构成了 3G 资本的用人哲学核心——<strong>PSD 型人才</strong>。</p>
<p>3G 资本，这家由三个巴西人创办的投资帝国，用这套人才策略，从一个巴西小券商起步，先后拿下了百威英博、汉堡王、卡夫亨氏、Tim Hortons，管理着超过 500 亿美元的资产。</p>
<p>他们的创始人雷曼说过一句话：<strong>「我们不需要最聪明的人，我们需要最饥饿的人。」</strong></p>
<h2>什么是 PSD 型人才？</h2>
<p><strong>P - Poor（贫穷）</strong></p>
<p>不是歧视穷人，而是一个现实的观察：出身贫寒的人，往往对「失去」有更强的恐惧，对「获得」有更强的渴望。他们没有退路，所以没有退路思维。</p>
<p><strong>S - Smart（聪明）</strong></p>
<p>这里的聪明不是指学历高，而是指<strong>解决问题的能力</strong>。3G 资本不在乎你读的是哈佛还是社区大学，他们在乎的是：你能不能在模糊的问题面前，快速找到可执行的路径。</p>
<p><strong>D - Deep Desire to Get Rich（强烈的致富野心）</strong></p>
<p>这不是贪婪，而是一种<strong>持续的驱动力</strong>。3G 资本相信，一个对财富有强烈渴望的人，在面对困难时不会轻易放弃——因为他知道自己要什么。</p>
<p><img src="/images/unsplash/photo-1507003211169-0a1dd7228f2d-40sbgd.jpg" alt="饥饿感"></p>
<h2>这套逻辑背后的心理学</h2>
<p>PSD 不是拍脑袋想出来的。它背后有深层的行为经济学原理：</p>
<h3>1. 损失厌恶 &gt; 收益渴望</h3>
<p>心理学家卡尼曼的研究表明，人对「失去 100 块」的痛苦，大约是对「获得 100 块」快乐的两倍。</p>
<p>出身贫寒的人，对「回到贫穷」的恐惧是真实且强烈的。这种恐惧会在潜意识层面驱动他们做出更努力、更审慎的决策。</p>
<p><strong>他们不是在追求成功，他们是在逃离失败。</strong> 这种驱动力比单纯的野心更持久。</p>
<h3>2. 延迟满足的能力</h3>
<p>研究表明，对最终回报有强烈渴望的人，更容易做到延迟满足。</p>
<p>PSD 型人才愿意接受前期的低薪、高强度、高压力，因为他们看到的是远期的丰厚回报。3G 资本的合伙人制度正好匹配了这个心理——前五年可能很苦，但如果你撑过来了，股权回报是指数级的。</p>
<h3>3. 内驱力 &gt; 外驱力</h3>
<p>很多名校毕业生的动力来自外部——父母的期望、社会的评价、同龄人的比较。当外部激励消失时，他们的动力也会消失。</p>
<p>PSD 型人才的动力来自内部——改变命运的渴望。这种动力不依赖外部环境，所以在逆境中更稳定。</p>
<p><img src="/images/unsplash/photo-1434030216411-0b793f4b4173-40sbgd.jpg" alt="驱动力"></p>
<h2>3G 资本是怎么用 PSD 模型的？</h2>
<h3>招聘：不看简历看饥饿感</h3>
<p>3G 资本的面试不会问「你在哪里实习过」，而是会问：</p>
<ul>
<li>你小时候家里是什么条件？</li>
<li>你做过最苦的工作是什么？</li>
<li>你为什么想要赚钱？</li>
<li>你愿意为了事业牺牲什么？</li>
</ul>
<p><strong>他们在寻找的不是完美的履历，而是燃烧的眼神。</strong></p>
<h3>培养：极简主义的精英训练</h3>
<p>进入 3G 资本的人，会经历一套被称为「PSD 大学」的培训体系：</p>
<p><strong>第一阶段：下一线。</strong> 不管你是哈佛 MBA 还是华尔街出身，入职后都要去工厂车间、去门店柜台。百威英博的高管必须在啤酒厂轮岗。</p>
<p><strong>第二阶段：数字驱动。</strong> 3G 资本是出了名的「数字狂魔」。每个决策都必须有数据支撑，每个汇报都必须精准到小数点。他们训练的是一种「用数据说话」的思维肌肉。</p>
<p><strong>第三阶段：结果问责。</strong> 没有借口，只有结果。达不成目标就要找出原因并改正，而不是解释为什么做不到。</p>
<p><img src="/images/unsplash/photo-1557804506-669a67965ba0-40sbgd.jpg" alt="精英训练"></p>
<h3>激励：合伙人制度</h3>
<p>3G 资本最核心的激励机制是<strong>合伙人制度</strong>。</p>
<p>表现优秀的人可以成为公司合伙人，分享整体利润。这不是奖金，这是<strong>所有权</strong>。</p>
<p>这个制度完美匹配了 PSD 模型：</p>
<ul>
<li><strong>对贫穷的恐惧</strong> → 不甘于只拿工资</li>
<li><strong>聪明</strong> → 能理解股权的价值远超短期薪酬</li>
<li><strong>致富野心</strong> → 合伙人制度提供了合法致富的最快路径</li>
</ul>
<h3>淘汰：零容忍的绩效文化</h3>
<p>PSD 不是终身制。3G 资本的绩效考核极其严格，每年淘汰排名后 10% 的人。</p>
<p>这套「不养闲人」的逻辑，确保了组织始终保持高压、高活力的状态。留下来的人知道，位置不是保障，表现才是。</p>
<p><img src="/images/unsplash/photo-1542744173-8e7e53415bb0-40sbgd.jpg" alt="绩效考核"></p>
<h2>3G 资本的经典战役：收购百威英博</h2>
<p>2008 年，3G 资本以 520 亿美元收购百威英博（Anheuser-Busch），这是啤酒行业历史上最大的并购案。</p>
<p>收购完成后，3G 走了三步：</p>
<p><strong>第一步：大规模裁员总部。</strong> 圣路易斯的百威总部从数百人缩减到几十人。砍掉的是「务虚」的岗位——公关、战略规划、企业文化部门。保留的是「务实」的人——运营、销售、财务。</p>
<p><strong>第二步：推行零基预算。</strong> 每一笔开支都要从零开始论证，不能因为「去年花了」就默认继续花。仅这一项，就为百威英博每年节省了数十亿美元。</p>
<p><strong>第三步：注入 PSD 文化。</strong> 把巴西团队的那套「饥饿 + 聪明 + 野心」的文化注入到这家百年企业中。</p>
<p>结果：百威英博在接下来的十年里，利润率从 25% 提升到了 40% 以上。</p>
<p><img src="/images/unsplash/photo-1517048676732-d65bc937f952-40sbgd.jpg" alt="商业并购"></p>
<h2>PSD 模型的局限性</h2>
<p>公平地说，PSD 模型不是万能的。它有几个明显的边界：</p>
<h3>1. 不适合所有行业</h3>
<p>PSD 模型在<strong>高度竞争、结果导向、可量化</strong>的行业效果最好——投资、零售、快消品、制造业。</p>
<p>但在需要创意、需要共情、需要长期主义的领域——比如教育、医疗、艺术——单纯靠「饥饿感」驱动可能会产生反效果。</p>
<h3>2. 可能导致短期主义</h3>
<p>极度渴望致富的人，有时会为了短期收益牺牲长期价值。3G 资本自己也踩过这个坑——为了追求利润率而过度削减研发和品牌投入，导致部分品牌的长期竞争力下降。</p>
<h3>3. 多样性的缺失</h3>
<p>当你的招聘标准高度同质化（穷 + 聪明 + 渴望致富），你的团队思维方式也会趋同。这在顺境中是效率优势，但在需要创新突破时可能是致命的盲区。</p>
<h3>4. 幸存者偏差</h3>
<p>我们看到的 3G 资本的成功，是无数 PSD 型人才中脱颖而出的那一小部分。大量同样「穷且聪明且渴望」的人，在残酷的淘汰机制中被消耗掉了。这不是一个「对所有人都好」的模式，这是一个「对组织好」的模式。</p>
<p><img src="/images/unsplash/photo-1551434678-e076c223a692-40sbgd.jpg" alt="反思"></p>
<h2>普通人能从 PSD 模型中学到什么？</h2>
<p>即使你不在 3G 资本工作，PSD 模型也给了我们一些关于「自我驱动」的启发：</p>
<h3>1. 找到你的「不安全感」</h3>
<p>每个人都有不安全感。有人怕穷，有人怕被看不起，有人怕平庸。这个不安全感不是坏事——<strong>它是你最稳定的驱动力来源</strong>。</p>
<p>关键是把它变成建设性的行动，而不是焦虑的情绪。</p>
<h3>2. 聪明是可以训练的</h3>
<p>3G 资本要的「聪明」不是天赋，而是<strong>解决问题的习惯</strong>：拆解问题、寻找数据、快速试错、持续迭代。这是任何人都可以培养的。</p>
<h3>3. 把野心说出来</h3>
<p>很多人有野心，但不敢说。PSD 型人才的特点是：<strong>他们不掩饰自己的渴望</strong>。</p>
<p>在一个组织里，明确表达「我想往上走、我想赚更多钱」的人，反而更容易被看见和培养。因为管理者知道该给他什么激励。</p>
<h3>4. 愿意吃苦，但要吃对苦</h3>
<p>PSD 不是让人盲目加班。它的真正含义是：<strong>你愿意为一个长期目标承受短期的不舒服</strong>。</p>
<p>这个「不舒服」可能是低薪、可能是高压、可能是远离家乡。但如果你清楚知道这个不舒服是为了什么，它就不是消耗，而是投资。</p>
<p><img src="/images/unsplash/photo-1519389950473-47ba0277781c-40sbgd.jpg" alt="自我驱动"></p>
<h2>写在最后</h2>
<p>3G 资本的 PSD 模型，本质上回答了一个关于人才的古老问题：</p>
<p><strong>在所有的能力、品质、背景中，什么是最能预测一个人未来成就的变量？</strong></p>
<p>他们的答案是：<strong>饥饿感。</strong></p>
<p>能力可以培养，经验可以积累，背景可以改变。但一个人内心深处那种「我一定要改变现状」的火焰，是最难培养也最珍贵的东西。</p>
<p>不管你是创始人、管理者还是普通职场人，这个洞察都值得思考：</p>
<p><strong>你团队里最「饥饿」的人是谁？你自己，还在「饥饿」吗？</strong></p>
<p><em>有时候，起点低不是劣势。起点低，意味着你没有东西可以失去，也就没有东西可以害怕。</em></p>
<p>&quot;</p>
]]></content>
    <category term="随笔"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI Agent 架构演进：从用户驱动到事件驱动</title>
    <id>https://www.fen9pi.cn/posts/agent-architecture-evolution/</id>
    <link href="https://www.fen9pi.cn/posts/agent-architecture-evolution/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：Agent 的下一次跃迁</h2>
<p><strong>2026-08-26 09:30 GMT+8</strong></p>
<p><strong>AI Agent 正在经历一次深刻的架构演进</strong>。
&quot;
从&quot;问答工具&quot;到&quot;数字员工&quot;，从&quot;被动响应&quot;到&quot;主动执行&quot;。</p>
<p>核心思想：<strong>Agent 的触发机制从&quot;用户驱动&quot;向&quot;事件驱动&quot;转变</strong>。</p>
<p><strong>一句话说清楚</strong>：</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：Agent 的下一次跃迁</h2>
<p><strong>2026-08-26 09:30 GMT+8</strong></p>
<p><strong>AI Agent 正在经历一次深刻的架构演进</strong>。
&quot;
从&quot;问答工具&quot;到&quot;数字员工&quot;，从&quot;被动响应&quot;到&quot;主动执行&quot;。</p>
<p>核心思想：<strong>Agent 的触发机制从&quot;用户驱动&quot;向&quot;事件驱动&quot;转变</strong>。</p>
<p><strong>一句话说清楚</strong>：</p>
<blockquote>
<p>下一代 Agent 架构中，触发源从单一的&quot;人&quot;扩展为&quot;人+系统+环境&quot;，Agent 从问答工具跃迁为数字员工</p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-08-26T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Agent as Code：如何把 Agent 相关的东西全部放到代码库？</title>
    <id>https://www.fen9pi.cn/posts/agent-as-code/</id>
    <link href="https://www.fen9pi.cn/posts/agent-as-code/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="代码库"></p>
<blockquote>
<p><strong>Infrastructure as Code</strong>（IaC）已经成了标准实践。</p>
<p>Terraform 管理基础设施，Kubernetes 管理容器，Ansible 管理配置。</p>
<p>但 AI Agent 时代，我们缺了一块：<strong>Agent as Code</strong>。</p>
<p>如何把 Agent 相关的一切——人设、技能、工作流、记忆——全部放进代码库？</p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="代码库"></p>
<blockquote>
<p><strong>Infrastructure as Code</strong>（IaC）已经成了标准实践。</p>
<p>Terraform 管理基础设施，Kubernetes 管理容器，Ansible 管理配置。</p>
<p>但 AI Agent 时代，我们缺了一块：<strong>Agent as Code</strong>。</p>
<p>如何把 Agent 相关的一切——人设、技能、工作流、记忆——全部放进代码库？</p>
</blockquote>
<h2>一个被忽视的问题</h2>
<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="孤立"></p>
<p>现在很多人玩 AI Agent，是这样的：</p>
<p>在 ChatGPT 网页版里，写一个「你是一个专业前端工程师」的 Prompt。然后在 Cursor 里，写另一个「你是一个代码审查专家」的 Prompt。又在 claude.ai 里，写第三个「你是一个产品经理」的 Prompt。</p>
<p><strong>这三个 Prompt 是孤立的。</strong></p>
<p><img src="/images/unsplash/photo-1454165804606-c3d57bc86b40-40sbgd.jpg" alt="混乱"></p>
<p>它们不在一个地方。它们没有版本控制。它们无法协同工作。</p>
<p>更糟糕的是：</p>
<ul>
<li>你改了 Prompt A，但忘了同步到 Prompt B</li>
<li>你团队里的三个人，各有各的 Prompt 版本</li>
<li>你不知道哪个 Agent 是在什么时候用什么配置跑的</li>
<li>出了问题，你无法复现</li>
</ul>
<p><strong>这不是工程化。这是「手工作坊」。</strong></p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-06-02T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Pi 的 AgentHarness v2：持久化 AI Agent 的革命性设计</title>
    <id>https://www.fen9pi.cn/posts/agent-harness-v2/</id>
    <link href="https://www.fen9pi.cn/posts/agent-harness-v2/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：为什么需要 AgentHarness？</h2>
<p>在 AI 时代，我们面临三个核心问题：</p>
<p><strong>1. 持久化问题</strong></p>
<ul>
<li>Agent 崩溃后，上下文丢失</li>
<li>重新开始，重复工作</li>
<li>无法恢复到崩溃前的状态</li>
</ul>
<p><strong>2. 并发问题</strong></p>
<ul>
<li>无法并行处理多个任务</li>
<li>资源利用率低</li>
<li>响应慢</li>
</ul>
<p><strong>3. 可观察性问题</strong></p>
<ul>
<li>无法追踪 Agent 的执行过程</li>
<li>调试困难</li>
<li>优化无从下手</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：为什么需要 AgentHarness？</h2>
<p>在 AI 时代，我们面临三个核心问题：</p>
<p><strong>1. 持久化问题</strong></p>
<ul>
<li>Agent 崩溃后，上下文丢失</li>
<li>重新开始，重复工作</li>
<li>无法恢复到崩溃前的状态</li>
</ul>
<p><strong>2. 并发问题</strong></p>
<ul>
<li>无法并行处理多个任务</li>
<li>资源利用率低</li>
<li>响应慢</li>
</ul>
<p><strong>3. 可观察性问题</strong></p>
<ul>
<li>无法追踪 Agent 的执行过程</li>
<li>调试困难</li>
<li>优化无从下手</li>
</ul>
<p><strong>AgentHarness v2</strong> 是 Pi 对这些问题的革命性解决方案。</p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-08-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">学Agent的顺序，其实是反的</title>
    <id>https://www.fen9pi.cn/posts/agent-learning-path/</id>
    <link href="https://www.fen9pi.cn/posts/agent-learning-path/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>开篇</h2>
<p>一个观察：很多人学 Agent，顺序是反的。</p>
<p>一上来就研究 Multi-Agent、Tree of Thought、Memory、Agentic RAG，架构图画了一张又一张，论文读了一篇又一篇。</p>
<p>真到自己动手——</p>
<p><strong>连一个能稳定跑起来的单 Agent 都做不出来。</strong></p>
<p>我见过聊 LangGraph 头头是道的人，问他「你的 Agent 怎么判断工具调用是成功还是失败」，愣住了。</p>
<p>不是能力问题，是顺序问题。</p>
<p></p>
<hr>
<h2>一、为什么都在追新概念</h2>]]></summary>
    <content type="html"><![CDATA[<h2>开篇</h2>
<p>一个观察：很多人学 Agent，顺序是反的。</p>
<p>一上来就研究 Multi-Agent、Tree of Thought、Memory、Agentic RAG，架构图画了一张又一张，论文读了一篇又一篇。</p>
<p>真到自己动手——</p>
<p><strong>连一个能稳定跑起来的单 Agent 都做不出来。</strong></p>
<p>我见过聊 LangGraph 头头是道的人，问他「你的 Agent 怎么判断工具调用是成功还是失败」，愣住了。</p>
<p>不是能力问题，是顺序问题。</p>
<p></p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-08-03T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">学习 Agent 的七步路线</title>
    <id>https://www.fen9pi.cn/posts/agent-learning-roadmap/</id>
    <link href="https://www.fen9pi.cn/posts/agent-learning-roadmap/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：如何系统学习 Agent</h2>
<p>很多人问我如何系统学习 AI Agent。</p>
<p>这是我的答案：</p>
<p><strong>一个学习 Agent 的简单线路。</strong></p>
<hr>
<h2>一、学习路线全景</h2>
<p></p>
<p><strong>七步路线</strong>：</p>
<ol>
<li>LLM 基础</li>
<li>LangChain</li>
<li>LangGraph</li>
<li>Agent 核心原理</li>
<li>Context Engineering</li>
<li>Agent Engineering</li>
<li>论文 + 源码</li>
<li>自己实现 + 做真实产品</li>
</ol>]]></summary>
    <content type="html"><![CDATA[<h2>前言：如何系统学习 Agent</h2>
<p>很多人问我如何系统学习 AI Agent。</p>
<p>这是我的答案：</p>
<p><strong>一个学习 Agent 的简单线路。</strong></p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-08-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI Agent的四种循环模式：从单回合到主动触发</title>
    <id>https://www.fen9pi.cn/posts/agent-loop-modes/</id>
    <link href="https://www.fen9pi.cn/posts/agent-loop-modes/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>不是问一次答一次，而是让AI自己迭代，直到目标达成。</p>
</blockquote>
<hr>
<h2>痛点</h2>
<p>传统AI使用方式：</p>
<p>你问一个问题，AI答一次。
&quot;
&quot;帮我写个函数&quot; → AI写个函数
&quot;帮我优化这段代码&quot; → AI优化代码
&quot;帮我写个测试&quot; → AI写测试</p>
<p><strong>一个问题一个回合，效率低。</strong></p>
<p>复杂任务需要多轮对话，人工介入，反复确认。</p>
<p><strong>为什么不让AI自己循环迭代，直到目标达成？</strong></p>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>不是问一次答一次，而是让AI自己迭代，直到目标达成。</p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-07T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">打造 Agent 组织的第一步：工具协同的三层境界</title>
    <id>https://www.fen9pi.cn/posts/agent-org-1/</id>
    <link href="https://www.fen9pi.cn/posts/agent-org-1/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551434678-e076c223a692-40sbgd.jpg" alt="Agent 组织工具协同"></p>
<blockquote>
<p><strong>如何打造一个真正敏捷的 Agent 组织？</strong></p>
<p><strong>第一步就是学会使用最顶尖的 AI 协同工具</strong></p>
<p><strong>三层协同：人与人、人与AI、AI与AI</strong></p>
<p><strong>GitLab + 飞书 CLI + 知识库，工具链贯通是效率提升的前提</strong></p>
<p><strong>来源：组织 Agent 化实践思考</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551434678-e076c223a692-40sbgd.jpg" alt="Agent 组织工具协同"></p>
<blockquote>
<p><strong>如何打造一个真正敏捷的 Agent 组织？</strong></p>
<p><strong>第一步就是学会使用最顶尖的 AI 协同工具</strong></p>
<p><strong>三层协同：人与人、人与AI、AI与AI</strong></p>
<p><strong>GitLab + 飞书 CLI + 知识库，工具链贯通是效率提升的前提</strong></p>
<p><strong>来源：组织 Agent 化实践思考</strong></p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Agent 组织的核心：团队 Memory 决定 AI 的组织能力</title>
    <id>https://www.fen9pi.cn/posts/agent-org-2/</id>
    <link href="https://www.fen9pi.cn/posts/agent-org-2/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="Agent 组织 Memory 系统"></p>
<blockquote>
<p><strong>AI 在组织上的能力取决于什么？</strong></p>
<p><strong>取决于组织的优质「上下文」</strong></p>
<p><strong>团队 Memory：团队、个人、项目、客户四层体系</strong></p>
<p><strong>谁掌握了高质量的上下文，谁就更有可能形成真正高效的协同与决策能力</strong></p>
<p><strong>来源：组织 Agent 化实践思考</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="Agent 组织 Memory 系统"></p>
<blockquote>
<p><strong>AI 在组织上的能力取决于什么？</strong></p>
<p><strong>取决于组织的优质「上下文」</strong></p>
<p><strong>团队 Memory：团队、个人、项目、客户四层体系</strong></p>
<p><strong>谁掌握了高质量的上下文，谁就更有可能形成真正高效的协同与决策能力</strong></p>
<p><strong>来源：组织 Agent 化实践思考</strong></p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">组织 Agent 化公式：工具 × Memory × 协议 × 人才 × 反馈</title>
    <id>https://www.fen9pi.cn/posts/agent-org-3/</id>
    <link href="https://www.fen9pi.cn/posts/agent-org-3/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1519389950473-47ba0277781c-40sbgd.jpg" alt="组织 Agent 化公式"></p>
<blockquote>
<p><strong>如何衡量一个组织的 Agent 化水平？</strong></p>
<p><strong>组织 Agent 化水平 = 工具贯通度 × Memory 质量 × 协议清晰度 × 人才密度 × 反馈迭代速度</strong></p>
<p><strong>决定这一切能否成立的，仍然是人本身</strong></p>
<p><strong>Agent 组织的核心：构建持续进化、持续协同、持续创造价值的组织系统</strong></p>
<p><strong>来源：组织 Agent 化实践思考</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1519389950473-47ba0277781c-40sbgd.jpg" alt="组织 Agent 化公式"></p>
<blockquote>
<p><strong>如何衡量一个组织的 Agent 化水平？</strong></p>
<p><strong>组织 Agent 化水平 = 工具贯通度 × Memory 质量 × 协议清晰度 × 人才密度 × 反馈迭代速度</strong></p>
<p><strong>决定这一切能否成立的，仍然是人本身</strong></p>
<p><strong>Agent 组织的核心：构建持续进化、持续协同、持续创造价值的组织系统</strong></p>
<p><strong>来源：组织 Agent 化实践思考</strong></p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Agent Reach：给AI Agent一键装上互联网能力</title>
    <id>https://www.fen9pi.cn/posts/agent-reach-intro/</id>
    <link href="https://www.fen9pi.cn/posts/agent-reach-intro/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>一句话安装，让你的Agent能读推特、刷小红书、看YouTube、搜Reddit。</p>
</blockquote>
<hr>
<h2>痛点</h2>
<p>AI Agent已经能帮你写代码、改文档、管项目——</p>
<p>但你让它去网上找点东西，它就抓瞎了：
&quot;</p>
<ul>
<li>📺 <strong>&quot;帮我看看这个YouTube教程讲了什么&quot;</strong> → 看不了，拿不到字幕</li>
<li>🐦 <strong>&quot;帮我搜一下推特上大家怎么评价这个产品&quot;</strong> → 搜不了，Twitter API要付费</li>
<li>📖 <strong>&quot;去Reddit上看看有没有人遇到过同样的bug&quot;</strong> → 403被封，服务器IP被拒</li>
<li>📕 <strong>&quot;帮我看看小红书上这个品的口碑&quot;</strong> → 打不开，必须登录才能看</li>
<li>📺 <strong>&quot;B站上有个技术视频，帮我总结一下&quot;</strong> → 拿不到，通用下载工具被B站风控全面拦截</li>
<li>🔍 <strong>&quot;帮我在网上搜一下最新的LLM框架对比&quot;</strong> → 没有好用的搜索，要么付费要么质量差</li>
<li>🌐 <strong>&quot;帮我看看这个网页写了啥&quot;</strong> → 抓回来一堆HTML标签，根本没法读</li>
<li>📦 <strong>&quot;这个GitHub仓库是干嘛的？Issue里说了什么？&quot;</strong> → 能用，但认证配置很麻烦</li>
<li>📡 <strong>&quot;帮我订阅这几个RSS源，有更新告诉我&quot;</strong> → 要自己装库写代码</li>
</ul>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>一句话安装，让你的Agent能读推特、刷小红书、看YouTube、搜Reddit。</p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-09T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI Agent 的「技能」和「工作流」：别让概念绑架了你的思考</title>
    <id>https://www.fen9pi.cn/posts/agent-skill-workflow/</id>
    <link href="https://www.fen9pi.cn/posts/agent-skill-workflow/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-40sbgd.jpg" alt="AI Agent"></p>
<blockquote>
<p>最近一年，「AI Agent」火得一塌糊涂。</p>
<p>但聊得最多的两个概念——「技能（Skill）」和「工作流（Workflow）」——很多人其实没搞清楚。</p>
<p>今天我想用最简单的语言，把它们说清楚。</p>
</blockquote>
<h2>先说一个被忽视的事实</h2>
<p><strong>AI Agent 本质上是一个「对话系统」+「工具调用能力」。</strong></p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-40sbgd.jpg" alt="AI Agent"></p>
<blockquote>
<p>最近一年，「AI Agent」火得一塌糊涂。</p>
<p>但聊得最多的两个概念——「技能（Skill）」和「工作流（Workflow）」——很多人其实没搞清楚。</p>
<p>今天我想用最简单的语言，把它们说清楚。</p>
</blockquote>
<h2>先说一个被忽视的事实</h2>
<p><strong>AI Agent 本质上是一个「对话系统」+「工具调用能力」。</strong></p>
<p>你跟它说话，它理解你的意图，然后决定：</p>
<ul>
<li>要不要调用工具</li>
<li>调用哪个工具</li>
<li>用什么参数调用</li>
<li>工具返回结果后怎么处理</li>
</ul>
<p>就这么简单。</p>
<p><strong>但就是这个「简单」，让无数人陷入了「概念陷阱」。</strong></p>
<p>有人觉得 Agent 必须有「自主思考能力」。
有人觉得 Agent 必须能「自我学习」。
有人觉得 Agent 必须能「跨工具协作」。</p>
<p><strong>这些想法都对。但它们忽略了一个更基础的问题：</strong></p>
<blockquote>
<p>你到底是想用 AI 帮你「完成一件事」，还是想用 AI 帮你「搭建一个系统」？</p>
</blockquote>
<p>如果是前者，你需要的是「技能」。如果是后者，你需要的是「工作流」。</p>
<p><strong>这两者不是同一个东西。</strong></p>
<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="技能 vs 工作流"></p>
<h2>什么是「技能（Skill）」？</h2>
<p><strong>技能 = Agent 的一份「能力说明书」。</strong></p>
<p>它告诉 Agent：面对某类任务，应该怎么做。</p>
<p>比如你给 Claude 安装一个「微信公众号发布」Skill。这个 Skill 的内容可能是：</p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>任务：发布 Markdown 文章到微信公众号</span></span>
<span class="line"><span>步骤：</span></span>
<span class="line"><span>1. 读取 Markdown 文件</span></span>
<span class="line"><span>2. 解析 frontmatter（title 和 cover）</span></span>
<span class="line"><span>3. 调用微信 API 获取 access_token</span></span>
<span class="line"><span>4. 上传封面图到微信图床</span></span>
<span class="line"><span>5. 转换 Markdown 为 HTML</span></span>
<span class="line"><span>6. 创建草稿</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>这就是一个技能。</strong></p>
<p>它把「发布到公众号」这件事，拆成了一个标准流程。Agent 只要「照着做」就行。</p>
<p><strong>关键点：技能是「单次完成」的。</strong></p>
<p>你触发一次，它执行一遍。执行完，任务结束。中间没有状态，没有记忆，没有分支。</p>
<p><strong>技能解决的问题：重复性任务。</strong></p>
<ul>
<li>发布文章到公众号</li>
<li>从网页提取内容</li>
<li>生成特定格式的报告</li>
<li>批量处理数据</li>
</ul>
<p>这些任务的共同特征是：<strong>流程固定，输入输出明确</strong>。</p>
<p>技能就是把这些固定流程固化下来，让 Agent 可以「一键完成」。</p>
<h2>什么是「工作流（Workflow）」？</h2>
<p><strong>工作流 = Agent 之间的「接力跑」。</strong></p>
<p>它不是「一个 Agent 做一件事」，而是「多个 Agent 协作完成一个复杂任务」。</p>
<p>比如「写一篇技术博客并发布」这个任务：</p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>Agent 1：理解需求 → 生成大纲</span></span>
<span class="line"><span>Agent 2：根据大纲写内容</span></span>
<span class="line"><span>Agent 3：审核内容质量</span></span>
<span class="line"><span>Agent 4：优化 SEO</span></span>
<span class="line"><span>Agent 5：发布到公众号</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>这就是一个工作流。</strong></p>
<p>每个 Agent 负责一个环节，环节之间通过「交接棒」传递：</p>
<ul>
<li>Agent 1 把大纲传给 Agent 2</li>
<li>Agent 2 把文章传给 Agent 3</li>
<li>Agent 3 把优化建议传给 Agent 4</li>
<li>Agent 4 把最终内容传给 Agent 5</li>
</ul>
<p><strong>关键点：工作流是「多步骤、多状态」的。</strong></p>
<p>每个环节的输出，是下一个环节的输入。中间有状态流转，有质量检查，有分支决策。</p>
<p><strong>工作流解决的问题：复杂任务。</strong></p>
<ul>
<li>产品开发（需求 → 设计 → 开发 → 测试 → 上线）</li>
<li>内容生产（选题 → 写作 → 审核 → 发布 → 分发）</li>
<li>数据分析（采集 → 清洗 → 分析 → 可视化 → 报告）</li>
</ul>
<p>这些任务的共同特征是：<strong>步骤多、环节多、需要协同</strong>。</p>
<h2>技能和工作流的本质区别</h2>
<p>| 维度 | 技能（Skill） | 工作流（Workflow） |
|</p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-06-01T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">你的 AGENTS.md 是个神经网络</title>
    <id>https://www.fen9pi.cn/posts/agentsmd-neural-net/</id>
    <link href="https://www.fen9pi.cn/posts/agentsmd-neural-net/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：如何维护好 AGENTS.md</h2>
<p>很多人发现维护 AGENTS.md / CLAUDE.md 很难。</p>
<p>常见的回答：&quot;</p>
<ul>
<li>&quot;我想什么就写什么&quot;</li>
<li>&quot;让 Agent 自己写&quot;</li>
</ul>
<p>我也一样，很长一段时间都是凭感觉写。</p>
<p>直到我发现了一个更好的方法：</p>
<p><strong>短版本：手写用户级的 AGENTS.md，把项目级的 AGENTS.md 当作神经网络来训练。</strong></p>
<hr>
<h2>一、四种糟糕状态</h2>]]></summary>
    <content type="html"><![CDATA[<h2>前言：如何维护好 AGENTS.md</h2>
<p>很多人发现维护 AGENTS.md / CLAUDE.md 很难。</p>
<p>常见的回答：&quot;</p>
<ul>
<li>&quot;我想什么就写什么&quot;</li>
<li>&quot;让 Agent 自己写&quot;</li>
</ul>
<p>我也一样，很长一段时间都是凭感觉写。</p>
<p>直到我发现了一个更好的方法：</p>
<p><strong>短版本：手写用户级的 AGENTS.md，把项目级的 AGENTS.md 当作神经网络来训练。</strong></p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-08-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 自治 Loop：Plan 驱动的 TDD 自测循环</title>
    <id>https://www.fen9pi.cn/posts/ai-autonomous-loop/</id>
    <link href="https://www.fen9pi.cn/posts/ai-autonomous-loop/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="AI 自治 Loop"></p>
<blockquote>
<p><strong>如何让 AI 自主完成开发并自测？</strong></p>
<p><strong>AI 自治 Loop：Plan 驱动的 TDD 自测循环</strong></p>
<p><strong>Plan 锁定上下文，测试驱动开发，自主修复，确定性验收</strong></p>
<p><strong>来源：研发自测实践</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="AI 自治 Loop"></p>
<blockquote>
<p><strong>如何让 AI 自主完成开发并自测？</strong></p>
<p><strong>AI 自治 Loop：Plan 驱动的 TDD 自测循环</strong></p>
<p><strong>Plan 锁定上下文，测试驱动开发，自主修复，确定性验收</strong></p>
<p><strong>来源：研发自测实践</strong></p>
</blockquote>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 自治 Loop：让 AI 学会&amp;quot;自我测试&amp;quot;的开发循环</title>
    <id>https://www.fen9pi.cn/posts/ai-autonomous-loop-v2/</id>
    <link href="https://www.fen9pi.cn/posts/ai-autonomous-loop-v2/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p>&quot;</p>
<h2>前言：当 AI 开始&quot;自测&quot;</h2>
<p>想象这样一个场景：</p>
<p>你给 AI 一个开发任务，然后就可以去喝咖啡了。AI 自己编写代码，自己运行测试，自己修复错误，直到所有测试通过——然后通知你：&quot;任务完成了&quot;。</p>
<p>这不是科幻小说，而是<strong>AI 自治 Loop</strong>正在实现的能力。</p>
<p>今天，我们就来探讨这个让 AI 能够&quot;自我测试&quot;的开发循环。</p>
<hr>
<h2>一、传统 AI 辅助开发的痛点</h2>
<h3>1.1 上下文漂移</h3>]]></summary>
    <content type="html"><![CDATA[<p>&quot;</p>
<h2>前言：当 AI 开始&quot;自测&quot;</h2>
<p>想象这样一个场景：</p>
<p>你给 AI 一个开发任务，然后就可以去喝咖啡了。AI 自己编写代码，自己运行测试，自己修复错误，直到所有测试通过——然后通知你：&quot;任务完成了&quot;。</p>
<p>这不是科幻小说，而是<strong>AI 自治 Loop</strong>正在实现的能力。</p>
<p>今天，我们就来探讨这个让 AI 能够&quot;自我测试&quot;的开发循环。</p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 编程的六次进化：从读书到安全防护，一条完整的成长路径</title>
    <id>https://www.fen9pi.cn/posts/ai-coding-evolution/</id>
    <link href="https://www.fen9pi.cn/posts/ai-coding-evolution/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="AI 编程的六次进化"></p>
<blockquote>
<p><strong>AI 编程不是一步到位的。</strong></p>
<p><strong>它有清晰的进化路径。</strong></p>
<p><strong>六个阶段：</strong></p>
<p>读书 → 学工具 → 注入方法论 → 加载专家 → 多角色编排 → 安全防护</p>
<p><strong>(book) (guide) (superpowers) (agents) (orchestrator) (shellward)</strong></p>
<p><strong>每个阶段都建立在前一个阶段的基础上。</strong></p>
<p><strong>跳过任何一个，都会留下隐患。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="AI 编程的六次进化"></p>
<blockquote>
<p><strong>AI 编程不是一步到位的。</strong></p>
<p><strong>它有清晰的进化路径。</strong></p>
<p><strong>六个阶段：</strong></p>
<p>读书 → 学工具 → 注入方法论 → 加载专家 → 多角色编排 → 安全防护</p>
<p><strong>(book) (guide) (superpowers) (agents) (orchestrator) (shellward)</strong></p>
<p><strong>每个阶段都建立在前一个阶段的基础上。</strong></p>
<p><strong>跳过任何一个，都会留下隐患。</strong></p>
</blockquote>
<h2>第一阶段：读书（Book）</h2>
<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="读书"></p>
<p><strong>问题：你不知道自己不知道什么。</strong></p>
<p>AI 编程的坑太多了：</p>
<ul>
<li>什么时候该写测试？</li>
<li>怎么和 AI 沟通需求？</li>
<li>AI 写的代码能信吗？</li>
<li>怎么避免 AI 幻觉？</li>
<li>如何审查 AI 的代码？</li>
</ul>
<p><strong>不是工具的问题。</strong></p>
<p><strong>是认知的问题。</strong></p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-08T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI编程也有L1-L4，你们团队现在在哪一级？</title>
    <id>https://www.fen9pi.cn/posts/ai-coding-levels/</id>
    <link href="https://www.fen9pi.cn/posts/ai-coding-levels/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>从定速巡航到城市道路，AI编程进化的四个阶段。</p>
</blockquote>
<hr>
<h2>智能驾驶的启示</h2>
<p>智能驾驶从L1到L4，每一步都是质的飞跃：</p>
<ul>
<li><strong>L1辅助驾驶</strong> — 定速巡航，解放油门</li>
<li><strong>L2部分自动驾驶</strong> — 自适应巡航，解放双脚</li>
<li><strong>L3有条件自动驾驶</strong> — 高速路自动驾驶，可以看手机</li>
<li><strong>L4高度自动驾驶</strong> — 城市道路，全程不用管</li>
</ul>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>从定速巡航到城市道路，AI编程进化的四个阶段。</p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-06T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI Development 系统化：从 Spec 到上线的完整闭环</title>
    <id>https://www.fen9pi.cn/posts/ai-development-system/</id>
    <link href="https://www.fen9pi.cn/posts/ai-development-system/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="AI Development 系统化"></p>
<blockquote>
<p><strong>为什么 AI 开发总是一锤子买卖？</strong></p>
<p><strong>为什么不能持续迭代和改进？</strong></p>
<p><strong>如何让 AI 开发变成可持续的系统化工程？</strong></p>
<p><strong>AI Development 系统化的答案：</strong></p>
<p><strong>从 Spec 到上线的完整闭环。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="AI Development 系统化"></p>
<blockquote>
<p><strong>为什么 AI 开发总是一锤子买卖？</strong></p>
<p><strong>为什么不能持续迭代和改进？</strong></p>
<p><strong>如何让 AI 开发变成可持续的系统化工程？</strong></p>
<p><strong>AI Development 系统化的答案：</strong></p>
<p><strong>从 Spec 到上线的完整闭环。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-25T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">用 AI 生成 E2E 测试：Browser Use 到 Playwright</title>
    <id>https://www.fen9pi.cn/posts/ai-e2e-testing/</id>
    <link href="https://www.fen9pi.cn/posts/ai-e2e-testing/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="AI 生成 E2E 测试"></p>
<blockquote>
<p><strong>如何用测试用例生成 E2E 测试？</strong></p>
<p><strong>这是 AI 在自动化测试中的落地实践问题。</strong></p>
<p><strong>传统 E2E 测试的痛点：编写成本高、维护成本高、覆盖场景有限。</strong></p>
<p><strong>AI 提供了一种新的可能性：让 AI 自主探索页面，生成测试脚本，再固化复用。</strong></p>
<p><strong>本文介绍一套「AI 探索生成 → 固化脚本复用 → AI 视觉兜底」的闭环测试方案。</strong></p>
<p><strong>核心目标：降低 E2E 脚本编写成本，同时解决传统自动化测试难以处理的前端视觉问题。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="AI 生成 E2E 测试"></p>
<blockquote>
<p><strong>如何用测试用例生成 E2E 测试？</strong></p>
<p><strong>这是 AI 在自动化测试中的落地实践问题。</strong></p>
<p><strong>传统 E2E 测试的痛点：编写成本高、维护成本高、覆盖场景有限。</strong></p>
<p><strong>AI 提供了一种新的可能性：让 AI 自主探索页面，生成测试脚本，再固化复用。</strong></p>
<p><strong>本文介绍一套「AI 探索生成 → 固化脚本复用 → AI 视觉兜底」的闭环测试方案。</strong></p>
<p><strong>核心目标：降低 E2E 脚本编写成本，同时解决传统自动化测试难以处理的前端视觉问题。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-17T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 工程化全景图：从需求到部署的完整流程</title>
    <id>https://www.fen9pi.cn/posts/ai-engineering/</id>
    <link href="https://www.fen9pi.cn/posts/ai-engineering/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/covers/ai-engineering.png" alt="题图">
&quot;</p>
<h2>前言：当 AI 遇到&quot;工程化&quot;</h2>
<p>想象这样一个场景：</p>
<p>你的团队决定引入 AI 来提升开发效率。你们尝试了各种 AI 工具，使用了各种 Prompt，但结果却不尽如人意：</p>
<ul>
<li>AI 生成的代码质量不稳定</li>
<li>需求理解偏差导致返工</li>
<li>缺乏质量门禁导致 Bug 频出</li>
<li>没有监控和复盘机制，问题反复出现</li>
</ul>
<p>问题出在哪里？</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/covers/ai-engineering.png" alt="题图">
&quot;</p>
<h2>前言：当 AI 遇到&quot;工程化&quot;</h2>
<p>想象这样一个场景：</p>
<p>你的团队决定引入 AI 来提升开发效率。你们尝试了各种 AI 工具，使用了各种 Prompt，但结果却不尽如人意：</p>
<ul>
<li>AI 生成的代码质量不稳定</li>
<li>需求理解偏差导致返工</li>
<li>缺乏质量门禁导致 Bug 频出</li>
<li>没有监控和复盘机制，问题反复出现</li>
</ul>
<p>问题出在哪里？</p>
<p>答案很简单：<strong>缺少工程化思维</strong>。</p>
<p>AI 不是&quot;魔法&quot;，而是需要系统化、流程化、可管理的工程实践。今天，我们就来探讨从需求到部署的完整 AI 工程化流程。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-22T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 工程的四层进化：从 Prompt 到 Loop</title>
    <id>https://www.fen9pi.cn/posts/ai-engineering-four-layers/</id>
    <link href="https://www.fen9pi.cn/posts/ai-engineering-four-layers/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1454165804606-c3d57bc86b40-40sbgd.jpg" alt="AI 工程四层进化"></p>
<blockquote>
<p><strong>每往上一层，你操心的东西就大一号。</strong></p>
<p><strong>从「一句话」（Prompt）</strong></p>
<p><strong>→ 到「一个窗口」（Context）</strong></p>
<p><strong>→ 再到「一次运行」（Harness）</strong></p>
<p><strong>→ 最后到「一整套自动跑的循环」（Loop）。</strong></p>
<p><strong>这就是 AI 工程的四层进化。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1454165804606-c3d57bc86b40-40sbgd.jpg" alt="AI 工程四层进化"></p>
<blockquote>
<p><strong>每往上一层，你操心的东西就大一号。</strong></p>
<p><strong>从「一句话」（Prompt）</strong></p>
<p><strong>→ 到「一个窗口」（Context）</strong></p>
<p><strong>→ 再到「一次运行」（Harness）</strong></p>
<p><strong>→ 最后到「一整套自动跑的循环」（Loop）。</strong></p>
<p><strong>这就是 AI 工程的四层进化。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-18T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">从 Prompt 到 Graph：AI 工程化的五个演进层次</title>
    <id>https://www.fen9pi.cn/posts/ai-engineering-levels/</id>
    <link href="https://www.fen9pi.cn/posts/ai-engineering-levels/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/covers/ai-engineering-levels.png" alt="题图"></p>
<h2>前言：AI 工程化的演进之路</h2>
<p>想象这样一个场景：</p>
<p>你刚开始用 AI，发现：</p>
<ul>
<li>简单的提示词效果不好 → 开始学习 <strong>Prompt Engineering</strong></li>
<li>提示词越来越长，难以管理 → 开始学习 <strong>Context Engineering</strong></li>
<li>需要调用工具和 API → 开始学习 <strong>Harness Engineering</strong></li>
<li>需要迭代和自我修复 → 开始学习 <strong>Loop Engineering</strong></li>
<li>需要多个 AI 协作 → 开始学习 <strong>Graph Engineering</strong></li>
</ul>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/covers/ai-engineering-levels.png" alt="题图"></p>
<h2>前言：AI 工程化的演进之路</h2>
<p>想象这样一个场景：</p>
<p>你刚开始用 AI，发现：</p>
<ul>
<li>简单的提示词效果不好 → 开始学习 <strong>Prompt Engineering</strong></li>
<li>提示词越来越长，难以管理 → 开始学习 <strong>Context Engineering</strong></li>
<li>需要调用工具和 API → 开始学习 <strong>Harness Engineering</strong></li>
<li>需要迭代和自我修复 → 开始学习 <strong>Loop Engineering</strong></li>
<li>需要多个 AI 协作 → 开始学习 <strong>Graph Engineering</strong></li>
</ul>
<p>这不仅是工具的演进，更是<strong>工程化思维的成熟</strong>。
&quot;
今天，我们就来对比这五个工程层次，看看它们如何一步步将 AI 从&quot;玩具&quot;变成&quot;生产力工具&quot;。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-28T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI时代，技术债为什么越来越贵？</title>
    <id>https://www.fen9pi.cn/posts/ai-era-tech-debt/</id>
    <link href="https://www.fen9pi.cn/posts/ai-era-tech-debt/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>欠债总要还，只是利息越来越高。</p>
</blockquote>
<h2>一句话定义</h2>
<p>技术债（Technical Debt）就是<strong>用眼前的便利换长期的代价</strong>——代码写得不干净，业务跑得通，但未来的每一次改动都在为过去的偷懒付利息。</p>
<p>这不是一个新概念。Ward Cunningham 在1992年就提出来了。但问题是：<strong>在AI时代，这笔债的利率涨得飞快。</strong></p>
<hr>
<h2>七大成因，每个都在AI时代被放大</h2>
<h3>1. 业务压力：先上线再说</h3>
<p>&quot;
功能没做完就得硬着头皮上线，于是补丁堆补丁，workaround套workaround。代码里埋着一堆&quot;暂时这样，回头再改&quot;的注释——然后就没有回头了。</p>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>欠债总要还，只是利息越来越高。</p>
</blockquote>
<h2>一句话定义</h2>
<p>技术债（Technical Debt）就是<strong>用眼前的便利换长期的代价</strong>——代码写得不干净，业务跑得通，但未来的每一次改动都在为过去的偷懒付利息。</p>
<p>这不是一个新概念。Ward Cunningham 在1992年就提出来了。但问题是：<strong>在AI时代，这笔债的利率涨得飞快。</strong></p>
]]></content>
    <category term="方法论"/>
    <published>2026-06-29T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">需求规格写不好，AI再多也没用</title>
    <id>https://www.fen9pi.cn/posts/ai-friendly-spec-methodology/</id>
    <link href="https://www.fen9pi.cn/posts/ai-friendly-spec-methodology/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>把PRD写成机器能读懂的样子。</p>
</blockquote>
<h2>这一代产品经理的尴尬</h2>
<p>&quot;
PM写完需求，开发说&quot;这里不清楚&quot;；</p>
<p>开发写完代码，测试说&quot;跟需求不一样&quot;；</p>
<p>测试写完用例，产品说&quot;这逻辑有点怪&quot;。</p>
<p>换了个AI，尴尬加倍——</p>
<p><strong>AI更不会问&quot;为什么&quot;，只会按字面意思执行。</strong></p>
<hr>
<h2>问题在哪？</h2>
<p>传统的PRD有三个致命伤：</p>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>把PRD写成机器能读懂的样子。</p>
</blockquote>
<h2>这一代产品经理的尴尬</h2>
<p>&quot;
PM写完需求，开发说&quot;这里不清楚&quot;；</p>
<p>开发写完代码，测试说&quot;跟需求不一样&quot;；</p>
<p>测试写完用例，产品说&quot;这逻辑有点怪&quot;。</p>
<p>换了个AI，尴尬加倍——</p>
<p><strong>AI更不会问&quot;为什么&quot;，只会按字面意思执行。</strong></p>
]]></content>
    <category term="方法论"/>
    <published>2026-06-29T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 撒谎成性？不，是它读的&amp;quot;参考书&amp;quot;有毒</title>
    <id>https://www.fen9pi.cn/posts/ai-hallucination-knowledge/</id>
    <link href="https://www.fen9pi.cn/posts/ai-hallucination-knowledge/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p>&quot;</p>
<h1>AI 撒谎成性？不，是它读的&quot;参考书&quot;有毒</h1>
<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-5zebmy.jpg" alt="AI幻觉"></p>
<blockquote>
<p>你问 AI 一个问题，它信誓旦旦给了个答案，你一查——全是编的。</p>
</blockquote>
<p>这事谁没遇到过？</p>
<hr>
<h2>一、一个令人背脊发凉的真实案例</h2>
<p><img src="/images/unsplash/photo-1554224155-8d04cb21cd6c-5zebmy.jpg" alt="实验结果"></p>]]></summary>
    <content type="html"><![CDATA[<p>&quot;</p>
<h1>AI 撒谎成性？不，是它读的&quot;参考书&quot;有毒</h1>
<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-5zebmy.jpg" alt="AI幻觉"></p>
<blockquote>
<p>你问 AI 一个问题，它信誓旦旦给了个答案，你一查——全是编的。</p>
</blockquote>
<p>这事谁没遇到过？</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-07T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 编程时代的代码验证：Lint 与视觉回归测试的新范式</title>
    <id>https://www.fen9pi.cn/posts/ai-lint-vrt/</id>
    <link href="https://www.fen9pi.cn/posts/ai-lint-vrt/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：AI 编程需要新的验证体系</h2>
<p>AI 写代码已经不新鲜了。但问题来了：AI 写的代码，谁来验证？</p>
<p>传统 Lint 检查语法和风格，视觉回归测试对比像素差异。这些方法在 AI 时代不够用了。</p>
<p>为什么？</p>
<ul>
<li>AI 生成代码速度快，人工 Review 跟不上</li>
<li>AI 能写 UI，但它看不到页面</li>
<li>AI 可能引入微妙的逻辑问题，传统 Lint 发现不了</li>
</ul>
<p>核心思路：<strong>验证左移，为 AI Agent 建立自动化的反馈闭环</strong>。</p>
<hr>]]></summary>
    <content type="html"><![CDATA[<h2>前言：AI 编程需要新的验证体系</h2>
<p>AI 写代码已经不新鲜了。但问题来了：AI 写的代码，谁来验证？</p>
<p>传统 Lint 检查语法和风格，视觉回归测试对比像素差异。这些方法在 AI 时代不够用了。</p>
<p>为什么？</p>
<ul>
<li>AI 生成代码速度快，人工 Review 跟不上</li>
<li>AI 能写 UI，但它看不到页面</li>
<li>AI 可能引入微妙的逻辑问题，传统 Lint 发现不了</li>
</ul>
<p>核心思路：<strong>验证左移，为 AI Agent 建立自动化的反馈闭环</strong>。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-08-26T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 成熟度五级：从「+AI」到「AI+」的演进阶梯</title>
    <id>https://www.fen9pi.cn/posts/ai-maturity-five-levels/</id>
    <link href="https://www.fen9pi.cn/posts/ai-maturity-five-levels/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="https://images.unsplash.com/photo-1536240478700-b869070f9279?w=677&amp;h=380&amp;fit=crop" alt="AI 成熟度模型"></p>
<blockquote>
<p><strong>模型的五个等级借鉴了经典的 CMMI 框架。</strong></p>
<p><strong>清晰地定义了企业应用 AI 的成熟度阶梯。</strong></p>
<p><strong>这五个阶段也反映了企业从利用 AI 作为辅助工具（「+AI」模式）到以 AI 为核心重构业务（「AI+」模式）的战略演进。</strong></p>
<p><strong>L1：探索试验级 → L5：认知引领级。</strong></p>
<p><strong>从「点」上的突破，到「线」上的赋能，到「面」上的优化，到「体」上的重构，到「场」上的引领。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="https://images.unsplash.com/photo-1536240478700-b869070f9279?w=677&amp;h=380&amp;fit=crop" alt="AI 成熟度模型"></p>
<blockquote>
<p><strong>模型的五个等级借鉴了经典的 CMMI 框架。</strong></p>
<p><strong>清晰地定义了企业应用 AI 的成熟度阶梯。</strong></p>
<p><strong>这五个阶段也反映了企业从利用 AI 作为辅助工具（「+AI」模式）到以 AI 为核心重构业务（「AI+」模式）的战略演进。</strong></p>
<p><strong>L1：探索试验级 → L5：认知引领级。</strong></p>
<p><strong>从「点」上的突破，到「线」上的赋能，到「面」上的优化，到「体」上的重构，到「场」上的引领。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-15T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 研发成熟度模型：你在哪一级，决定了你该用什么</title>
    <id>https://www.fen9pi.cn/posts/ai-maturity-model/</id>
    <link href="https://www.fen9pi.cn/posts/ai-maturity-model/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="AI 研发成熟度模型"></p>
<blockquote>
<p><strong>不是谁都需要全套。</strong></p>
<p><strong>你在哪一级，决定了你该用什么。</strong></p>
<p><strong>从裸奔的 Vibe Coding 到多 Agent 自动协作，</strong></p>
<p><strong>五个级别，每个级别都有自己的工具和方法。</strong></p>
<p><strong>关键是：认清自己的级别，用对工具。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="AI 研发成熟度模型"></p>
<blockquote>
<p><strong>不是谁都需要全套。</strong></p>
<p><strong>你在哪一级，决定了你该用什么。</strong></p>
<p><strong>从裸奔的 Vibe Coding 到多 Agent 自动协作，</strong></p>
<p><strong>五个级别，每个级别都有自己的工具和方法。</strong></p>
<p><strong>关键是：认清自己的级别，用对工具。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-08T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 原生 SDLC 实践手册：重新定义软件开发流程</title>
    <id>https://www.fen9pi.cn/posts/ai-native-sdlc/</id>
    <link href="https://www.fen9pi.cn/posts/ai-native-sdlc/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：AI 时代的软件开发新范式</h2>
<p><strong>2026-08-26 10:08 GMT+8</strong></p>
<p><strong>传统 SDLC 正在经历根本性的变革</strong>。</p>
<p>AI 不仅仅是加速开发，而是<strong>重新定义了软件开发的每一个环节</strong>。</p>
<p>从需求分析到设计、编码、测试、部署、运维，AI 正在改变我们构建软件的方式。</p>
<p><strong>一句话说清楚</strong>：&quot;</p>
<blockquote>
<p>AI 原生 SDLC 不是在传统流程中加 AI 工具，而是以 AI 为核心重新设计整个软件开发生命周期——从&quot;辅助工具&quot;到&quot;核心引擎&quot;</p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<h2>前言：AI 时代的软件开发新范式</h2>
<p><strong>2026-08-26 10:08 GMT+8</strong></p>
<p><strong>传统 SDLC 正在经历根本性的变革</strong>。</p>
<p>AI 不仅仅是加速开发，而是<strong>重新定义了软件开发的每一个环节</strong>。</p>
<p>从需求分析到设计、编码、测试、部署、运维，AI 正在改变我们构建软件的方式。</p>
<p><strong>一句话说清楚</strong>：&quot;</p>
<blockquote>
<p>AI 原生 SDLC 不是在传统流程中加 AI 工具，而是以 AI 为核心重新设计整个软件开发生命周期——从&quot;辅助工具&quot;到&quot;核心引擎&quot;</p>
</blockquote>
]]></content>
    <category term="方法论"/>
    <published>2026-08-26T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 辅助 OPC：一人公司的创业新范式</title>
    <id>https://www.fen9pi.cn/posts/ai-opc/</id>
    <link href="https://www.fen9pi.cn/posts/ai-opc/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="AI 辅助 OPC"></p>
<blockquote>
<p><strong>传统的创业增长曲线大致遵循这样的节奏：验证 &gt; 融资 &gt; 招人 &gt; 开发 &gt; 再融资 &gt; 增长 &gt; 再招人 &gt; 循环。</strong></p>
<p><strong>如今，AI 已经擦掉了这条隐含假设——每进入下一个阶段都必须更大的团队、新的技能组合、新的一轮融资。</strong></p>
<p><strong>AI 把创业四个核心阶段（Idea（创意验证）、MVP（最小可行）、Launch（公开上线）、Scale（规模扩张））重新画了一遍地图。</strong></p>
<p><strong>对比两种范式，AI 辅助 OPC（One-Person Company，一人公司）成为可能。</strong></p>
<p><strong>从「团队驱动」到「AI 辅助的个人驱动」，创业的游戏规则正在被重写。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="AI 辅助 OPC"></p>
<blockquote>
<p><strong>传统的创业增长曲线大致遵循这样的节奏：验证 &gt; 融资 &gt; 招人 &gt; 开发 &gt; 再融资 &gt; 增长 &gt; 再招人 &gt; 循环。</strong></p>
<p><strong>如今，AI 已经擦掉了这条隐含假设——每进入下一个阶段都必须更大的团队、新的技能组合、新的一轮融资。</strong></p>
<p><strong>AI 把创业四个核心阶段（Idea（创意验证）、MVP（最小可行）、Launch（公开上线）、Scale（规模扩张））重新画了一遍地图。</strong></p>
<p><strong>对比两种范式，AI 辅助 OPC（One-Person Company，一人公司）成为可能。</strong></p>
<p><strong>从「团队驱动」到「AI 辅助的个人驱动」，创业的游戏规则正在被重写。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-17T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">当 AI 接管大厂流程：每个环节都能被重塑</title>
    <id>https://www.fen9pi.cn/posts/ai-optimize-flow/</id>
    <link href="https://www.fen9pi.cn/posts/ai-optimize-flow/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="AI 重塑流程"></p>
<blockquote>
<p>一个像样的功能，从需求到上线要走六道关卡。AI 不是帮你在每道关卡跑得更快，而是直接改写了每道关卡的游戏规则。</p>
</blockquote>
<p>上一篇文章我们讨论了如何通过并行化、消除等待来优化流程。那些优化是「在现有规则内做得更快」。</p>
<p>但 AI 带来的改变，是另一个维度的——<strong>它让某些环节的定义本身发生了变化。</strong></p>
<p>让我们一个环节一个环节地看，AI 到底在做什么。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="AI 重塑流程"></p>
<blockquote>
<p>一个像样的功能，从需求到上线要走六道关卡。AI 不是帮你在每道关卡跑得更快，而是直接改写了每道关卡的游戏规则。</p>
</blockquote>
<p>上一篇文章我们讨论了如何通过并行化、消除等待来优化流程。那些优化是「在现有规则内做得更快」。</p>
<p>但 AI 带来的改变，是另一个维度的——<strong>它让某些环节的定义本身发生了变化。</strong></p>
<p>让我们一个环节一个环节地看，AI 到底在做什么。</p>
<h2>需求阶段：从「写 PRD」到「验证 PRD」</h2>
<p>传统流程：产品经理花 2-3 天写一份 PRD，描述要做什么、为什么做、做成什么样。</p>
<p><strong>AI 改变了什么？</strong></p>
<p>AI 没有替代产品经理写 PRD。PRD 的核心价值是<strong>决策</strong>——什么做、什么不做、优先级怎么排。这些决策需要对业务的理解、对用户的洞察、对资源的判断。AI 目前做不好这些。</p>
<p>但 AI 改变了 PRD 的「生产效率」和「验证效率」：</p>
<p><strong>生产端：</strong> 产品描述需求意图，AI 生成 PRD 初稿。产品的工作从「从零写文档」变成「修改和完善文档」。写作时间从 2 天压缩到半天。</p>
<p><strong>验证端：</strong> AI 阅读 PRD 后，自动提出遗漏问题——</p>
<ul>
<li>「这个功能在弱网环境下有设计吗？」</li>
<li>「竞品 A 做了类似功能，用户反馈不佳，你的方案有什么不同？」</li>
<li>「这个需求和上季度已上线的功能 X 有逻辑冲突。」</li>
</ul>
<p>以前这些问题要在需求评审会上被开发和测试「拷问」出来。现在 AI 在写 PRD 的时候就帮你扫了一遍。</p>
<p><strong>效果：需求评审从「挑毛病大会」变成「确认决策会」，评审时间从 2 小时缩短到 30 分钟。</strong></p>
<p><img src="https://images.unsplash.com/photo-1563986768609-322da13575f2?w=677&amp;h=380&amp;fit=crop" alt="AI 需求分析"></p>
<h2>设计阶段：从「出稿」到「出方案」</h2>
<p>传统流程：设计师出交互稿 → 评审 → 修改 → 出视觉稿 → 评审 → 定稿。一轮下来 5-7 天。</p>
<p><strong>AI 改变了什么？</strong></p>
<p><strong>交互设计端：</strong> AI 根据 PRD 生成多套交互方案原型。设计师的工作从「画界面」变成「选择和优化」。一天内可以对比 5-6 种方案，而不是只能出 1-2 种。</p>
<p><strong>技术方案端：</strong> 这是 AI 影响最大的环节之一。</p>
<p>写技术方案最耗时的不是「想架构」，而是<strong>调研和论证</strong>——</p>
<ul>
<li>这个场景用 Redis 还是本地缓存？</li>
<li>这种数据量需要分库分表吗？</li>
<li>这个并发量需要消息队列吗？</li>
</ul>
<p>以前 Tech Lead 要花 1-2 天查资料、看文档、写方案。现在 AI 可以在几分钟内给出多种方案的对比分析，包括每种方案的优缺点、适用场景、潜在风险。</p>
<p>Tech Lead 的工作从「从零构建方案」变成「评估 AI 给出的方案并做决策」。</p>
<p><strong>效果：技术方案产出时间从 3-5 天压缩到 1-2 天。技术评审从「方案讨论会」变成「方案决策会」。</strong></p>
<p><img src="https://images.unsplash.com/photo-1558618666-fcd25c85f82e?w=677&amp;h=380&amp;fit=crop" alt="AI 设计"></p>
<h2>开发阶段：从「写代码」到「审代码」</h2>
<p>传统流程：工程师写代码 → 联调 → Code Review。核心耗时 5-15 天。</p>
<p><strong>AI 改变了什么？</strong></p>
<p>这是所有人最关注的环节，也是 AI 能力渗透最深的环节。</p>
<p><strong>代码生成：</strong> AI 辅助编码已经不是新鲜事。但变化在于程度——</p>
<ul>
<li>样板代码（CRUD、数据模型、API 接口定义）：AI 可以生成 80-90%</li>
<li>业务逻辑代码：AI 可以生成 40-60%，需要人工修正</li>
<li>复杂算法和架构代码：AI 可以提供参考实现，人工主导</li>
</ul>
<p>综合来看，开发效率提升 30-50% 是可实现的。</p>
<p><strong>联调：</strong> AI 自动生成接口 Mock 数据、生成联调用例、甚至自动检测前后端接口不一致。</p>
<p>以前联调是两个人坐在一起「对暗号」。现在 AI 先帮你们对一遍，真正的联调只处理 AI 没覆盖到的边界情况。</p>
<p><strong>Code Review：</strong> AI 先做第一轮自动审查——检查代码规范、安全漏洞、性能隐患、常见 Bug 模式。人工 Code Review 集中在<strong>设计层面</strong>的审查——架构合理性、可维护性、业务逻辑正确性。</p>
<p><strong>效果：开发阶段从 5-15 天压缩到 3-8 天。工程师的角色从「代码生产者」变成「代码决策者」。</strong></p>
<p><img src="/images/unsplash/photo-1504639725590-34d0984388bd-40sbgd.jpg" alt="AI 编程"></p>
<h2>测试阶段：从「人找 Bug」到「人定边界」</h2>
<p>传统流程：QA 写测试用例 → 执行测试 → 提 Bug → 开发修 → 回归测试。Bug 循环跑 2-5 轮，耗时 5-10 天。</p>
<p><strong>AI 改变了什么？</strong></p>
<p><strong>测试用例生成：</strong> AI 阅读 PRD 和技术方案后，自动生成测试用例初稿——覆盖正常流程、异常流程、边界条件。QA 的工作从「写用例」变成「审核和补充用例」。</p>
<p><strong>自动化测试脚本：</strong> AI 根据测试用例自动生成自动化测试脚本。以前 QA 要手动编写 Selenium/Appium 脚本，现在 AI 可以根据界面操作描述直接生成。</p>
<p><strong>探索性测试：</strong> AI 还不能替代探索性测试——那种「我感觉这里会出问题」的直觉判断。但 AI 可以通过代码分析，<strong>主动提示</strong>高风险区域——</p>
<ul>
<li>「这个模块最近修改频率最高，建议重点测试」</li>
<li>「这个接口有 3 个未覆盖的异常分支」</li>
<li>「这个功能依赖的外部服务最近变更过」</li>
</ul>
<p><strong>Bug 修复加速：</strong> AI 根据 Bug 描述自动定位可能的代码位置，甚至给出修复建议。开发修 Bug 的时间从「定位 + 修复」变成基本只剩下「确认 + 修复」。</p>
<p><strong>效果：测试阶段从 5-10 天压缩到 3-5 天。Bug 循环从 3-5 轮减少到 1-2 轮。</strong></p>
<p><img src="/images/unsplash/photo-1535378917042-10a22c95931a-40sbgd.jpg" alt="AI 测试"></p>
<h2>上线阶段：从「盯大盘」到「AI 当哨兵」</h2>
<p>传统流程：灰度观察 → 全量发布 → 值班盯监控。高度依赖人的注意力和判断力。</p>
<p><strong>AI 改变了什么？</strong></p>
<p><strong>智能灰度：</strong> AI 实时分析灰度期间的数百个指标，自动判断是否可以扩大灰度范围。不需要人盯着大盘看数据曲线。</p>
<p><strong>异常预警：</strong> AI 不只是「指标超过阈值就告警」。它能识别<strong>趋势性异常</strong>——某个指标虽然还没超阈值，但正在以异常速度恶化。这种「预判性告警」能比传统监控提前 30 分钟到 2 小时发现问题。</p>
<p><strong>自动决策：</strong> 在预设策略范围内，AI 可以自动执行应急操作——</p>
<ul>
<li>流量异常 → 自动扩容</li>
<li>错误率上升 → 自动回滚</li>
<li>某功能异常 → 自动关闭 Feature Flag</li>
</ul>
<p>人的角色从「执行者」变成「策略制定者」——你定规则，AI 执行规则。</p>
<p><strong>效果：上线阶段的「人盯人」模式基本消除。值班工程师从 24 小时守着大盘变成只在 AI 需要决策时介入。</strong></p>
<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="AI 监控"></p>
<h2>验证回收：从「人工复盘」到「数据复盘」</h2>
<p>传统流程：上线后等 1-4 周看数据，开会复盘，整理归档。</p>
<p><strong>AI 改变了什么？</strong></p>
<p><strong>自动数据验证：</strong> 上线后，AI 自动追踪 PRD 中定义的所有目标指标。不需要人手动去数据平台拉报表。当数据异常时（指标没达到预期），AI 主动通知产品和技术负责人。</p>
<p><strong>智能复盘：</strong> AI 分析整个项目的完整数据——需求变更次数、Bug 数量趋势、代码变更频率、部署次数——自动生成项目复盘报告初稿。</p>
<p>复盘会不再需要花一个小时「回顾发生了什么」，而是直接讨论「为什么会这样」和「下次怎么改」。</p>
<p><strong>知识归档：</strong> AI 自动将项目中的关键决策、踩过的坑、有效的方案沉淀为可搜索的知识库。三个月后有人问「当初为什么这样设计」，AI 能直接回答。</p>
<p><strong>效果：验证回收从「被动等数据」变成「主动推送洞察」。复盘从「讲故事」变成「做决策」。</strong></p>
<p><img src="/images/unsplash/photo-1550751827-4bd374c3f58b-40sbgd.jpg" alt="AI 数据分析"></p>
<h2>全流程对比</h2>
<p>| 环节 | 传统方式 | AI 参与后 | 核心变化 |
|</p>
]]></content>
    <category term="方法论"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 铸造师：在 AI 时代，最值钱的能力是「复制自己」</title>
    <id>https://www.fen9pi.cn/posts/ai-smith/</id>
    <link href="https://www.fen9pi.cn/posts/ai-smith/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1620712943543-bcc4688e7485-40sbgd.jpg" alt="AI 铸造师"></p>
<blockquote>
<p>AI 时代的超级个体，不是一个人做更多事。是一群「AI 自己」替你做所有事。</p>
</blockquote>
<p>传统软件时代，如果你想做一个产品，你需要组建一个团队：产品经理、设计师、前端开发、后端开发、测试、运维。</p>
<p>你想做更多事，你就需要更多人。你想做得更好，你需要更专业的人。</p>
<p><strong>这是线性增长。</strong></p>
<p>AI 时代，有一个完全不同的模式：<strong>你不是雇佣更多人，而是铸造更多「AI 自己」。</strong></p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1620712943543-bcc4688e7485-40sbgd.jpg" alt="AI 铸造师"></p>
<blockquote>
<p>AI 时代的超级个体，不是一个人做更多事。是一群「AI 自己」替你做所有事。</p>
</blockquote>
<p>传统软件时代，如果你想做一个产品，你需要组建一个团队：产品经理、设计师、前端开发、后端开发、测试、运维。</p>
<p>你想做更多事，你就需要更多人。你想做得更好，你需要更专业的人。</p>
<p><strong>这是线性增长。</strong></p>
<p>AI 时代，有一个完全不同的模式：<strong>你不是雇佣更多人，而是铸造更多「AI 自己」。</strong></p>
<p>这个人有你的思维方式、有你解决问题的框架、有你的专业判断。但它可以在你需要的时候，瞬间复制成 100 个、1000 个、10000 个副本。</p>
<p><strong>这是指数增长。</strong></p>
<p>这个模式的核心，是一个新的角色——<strong>AI 铸造师</strong>。</p>
<h2>什么是 AI 铸造师？</h2>
<p>AI 铸造师不是「使用 AI 的人」。使用 AI 的人，是把 AI 当工具——你给 AI 一个任务，AI 完成任务。</p>
<p>AI 铸造师是<strong>设计 AI 的人</strong>。你不仅用 AI，你还铸造 AI——你设计它的人格、沉淀它的知识、构建它的技能、让它能像你一样思考。</p>
<p>然后，你让这个 AI 替你工作。</p>
<p><strong>AI 铸造师的核心能力：把自己「蒸馏」成 AI。</strong></p>
<h2>为什么是「铸造」？</h2>
<p>「铸造」这个词，来自于金属加工。你做一个模具，然后把熔化的金属倒进去，冷却后你就得到了一个和模具一模一样的铸件。</p>
<p><strong>关键点：一次设计，无限复制。</strong></p>
<p>AI 铸造师做的事情类似：</p>
<ol>
<li><strong>设计模具</strong> —— 定义 AI 的人设、知识框架、决策逻辑</li>
<li><strong>铸造副本</strong> —— 基于这个设计，创建无数个 AI 实例</li>
<li><strong>持续优化</strong> —— 根据反馈不断改进模具，越铸越精</li>
</ol>
<p><strong>你不是在雇佣 AI 助手。你是在铸造「自己」的数字版本。</strong></p>
<h2>AI 铸造师的三个核心能力</h2>
<h3>能力一：Agent 设计 —— 铸「人设」</h3>
<p>设计一个 AI，不是写一段 prompt。是在设计一个「人」。</p>
<p>这个人需要有：</p>
<p><strong>清晰的身份定位：</strong> 它是谁？它的专业领域是什么？它能解决什么问题？</p>
<p><strong>稳定的思维框架：</strong> 它遇到问题会怎么思考？它的决策逻辑是什么？它的价值观是什么？</p>
<p><strong>可执行的知识体系：</strong> 它需要什么知识？这些知识如何组织？如何在执行时快速检索？</p>
<p><strong>一致的交互风格：</strong> 它和用户对话的风格是什么？严谨还是随和？直接还是委婉？</p>
<p><strong>这些都是「人设」。一个好的 Agent 人设，不是一堆提示词，而是一个完整的人格模型。</strong></p>
<p>OpenClaw 中的 <code>SOUL.md</code> 就是这种人设文件的典型——它定义了 AI 的人格、口吻、价值观。</p>
<h3>能力二：Skill 构建 —— 铸「能力」</h3>
<p>人设决定了「AI 是谁」。Skill 决定了「AI 能做什么」。</p>
<p>一个 Skill 不是一段代码。它是<strong>一个完整的能力包</strong>，包括：</p>
<p><strong>知识库：</strong> 这个领域有哪些核心概念、常见问题、最佳实践？</p>
<p><strong>工具集：</strong> 这个领域需要用到什么工具？API、数据库、文件系统？</p>
<p><strong>工作流：</strong> 遇到这类问题，应该按什么步骤解决？</p>
<p><strong>质量标准：</strong> 什么样的输出是合格的？什么样的结果需要返工？</p>
<p><strong>比如一个「代码审查 Skill」，它不只是会看代码。它知道：</strong></p>
<ul>
<li>审查时关注什么（安全性、性能、可维护性）</li>
<li>什么样的代码是好代码（有文档、有测试、符合规范）</li>
<li>遇到问题怎么反馈（给具体建议、不只是挑错）</li>
<li>什么情况需要升级（严重安全问题、架构缺陷）</li>
</ul>
<p><strong>这就是一个「能力」，而不只是一个「功能」。</strong></p>
<h3>能力三：反馈闭环 —— 铸「进化」</h3>
<p>铸造一个 AI 不是一次性的工作。是持续优化的过程。</p>
<p>你铸造的 AI 会遇到各种情况：有些任务它做得很好，有些任务它做得不够好，有些任务它会犯错。</p>
<p><strong>这些反馈，是你改进模具的最好素材。</strong></p>
<p>反馈闭环的核心是：<strong>把「经验」沉淀回「模具」。</strong></p>
<p>具体怎么做？</p>
<p><strong>记录：</strong> 每个 Agent 执行任务时，记录它的输入、输出、用户反馈。</p>
<p><strong>分析：</strong> 定期分析这些数据，找出 Agent 的弱点——哪些类型的任务它总做不好？什么样的反馈它总收到？</p>
<p><strong>迭代：</strong> 根据分析结果，更新 Agent 的人设、更新 Skill 的知识、优化工作流。</p>
<p><strong>这就像人类的成长——你经历了事，你从中学到东西，你变得更聪明。AI 也一样。</strong></p>
<p>OpenClaw 的 <code>MEMORY.md</code> 和记忆系统，就是这个闭环的关键载体。</p>
<h2>多 Agent 协作的复利</h2>
<p>铸造一个 AI 已经很有价值。但真正的魔力，在于<strong>铸造多个 AI，让它们协作</strong>。</p>
<p>为什么？</p>
<p><strong>因为专业分工。</strong></p>
<p>一个人再强，也只能是一个人。但 10 个不同领域的 AI，就是 10 个专家。</p>
<p>比如你可以铸造：</p>
<ul>
<li><strong>需求分析 Agent</strong> —— 专门负责理解用户需求、拆解问题</li>
<li><strong>架构设计 Agent</strong> —— 专门负责设计系统架构、选择技术栈</li>
<li><strong>代码实现 Agent</strong> —— 专门负责写代码、实现功能</li>
<li><strong>测试审查 Agent</strong> —— 专门负责写测试、审查代码</li>
<li><strong>文档编写 Agent</strong> —— 专门负责写文档、维护知识库</li>
</ul>
<p>这些 Agent 不是各自为战。它们是一个<strong>工作流</strong>：</p>
<p>需求 Agent 把分析结果传给架构 Agent → 架构 Agent 把设计方案传给实现 Agent → 实现 Agent 把代码传给测试 Agent → 测试 Agent 把结果反馈给前面的环节</p>
<p><strong>这不是「多个人讨论」。这是「多个专家接力」。</strong></p>
<p>每个 AI 都在自己最擅长的环节工作。每个环节的输出，是下一个环节的输入。整个工作流的质量，是所有环节质量的最小值。</p>
<p><strong>这就是复利。</strong></p>
<p>当你有 5 个专业 Agent，每个 Agent 的质量提升 10%，整个工作流的质量提升不是 50%，是 1.1 的 5 次方——<strong>1.61 倍。</strong></p>
<p>持续迭代下去，这个增长是指数级的。</p>
<h2>从线性到指数：AI 铸造师的开挂模式</h2>
<p>传统工作模式是线性的：你投入 1 倍时间，得到 1 倍产出。你想得到 2 倍产出，你就投入 2 倍时间。</p>
<p>AI 铸造师模式是指数的：你投入 1 倍时间设计一个 Agent，这个 Agent 可以替你工作无数次。</p>
<p><strong>更进一步，你可以设计一个「铸造 Agent」。</strong></p>
<p>这个 Agent 专门负责根据你的需求，自动铸造新的 Agent。</p>
<p>你告诉它：「我需要一个能帮我做竞品分析的 AI。」</p>
<p>它会：</p>
<ol>
<li>分析竞品分析需要什么能力（信息收集、数据处理、报告撰写）</li>
<li>设计对应的 Agent 人设（专业、客观、有洞察力）</li>
<li>构建需要的 Skill（数据源、分析框架、报告模板）</li>
<li>创建这个 Agent 并让它开始工作</li>
</ol>
<p><strong>你不再是直接执行。你是在设计「能执行的设计者」。</strong></p>
<p>这是开挂模式。</p>
<h2>现在就能做的五件事</h2>
<p>你不需要等未来。你今天就可以开始做一个 AI 铸造师。</p>
<h3>第一件事：定义自己</h3>
<p>你是一个什么角色？你的专业领域是什么？你解决什么类型的问题？</p>
<p>把这些写下来。这是你铸造第一个 AI 的基础。</p>
<p><strong>你不是在复制你的技能。你是在复制你的「问题解决框架」。</strong></p>
<h3>第二件事：沉淀知识</h3>
<p>你领域里有哪些核心知识？常见问题？最佳实践？</p>
<p>把这些组织成一个结构化的知识库。这是你的 Agent 需要的「教材」。</p>
<p><strong>知识不是零散的笔记。是有组织的、可检索的、可执行的知识体系。</strong></p>
<h3>第三件事：设计第一个 Skill</h3>
<p>从你最擅长的一件事开始。比如「代码审查」、「需求分析」、「竞品调研」。</p>
<p>为这件事设计一个完整的工作流：输入是什么、处理步骤是什么、输出是什么、质量标准是什么。</p>
<p><strong>这就是一个 Skill 的雏形。</strong></p>
<h3>第四件事：铸造第一个 Agent</h3>
<p>用你定义的人设、你沉淀的知识、你设计的 Skill，创建第一个 Agent。</p>
<p>然后让它工作。观察它的表现。收集反馈。</p>
<p><strong>这是你的第一个「数字自己」。</strong></p>
<h3>第五件事：建立反馈闭环</h3>
<p>记录这个 Agent 的每一次执行。分析它哪里做得好、哪里不够好。</p>
<p>根据这些反馈，不断优化人设、更新知识、改进工作流。</p>
<p><strong>这不是一次性的铸造。这是持续的成长。</strong></p>
<h2>AI 铸造师的伦理思考</h2>
<p>当我们谈到「铸造 AI」时，有一个问题绕不开：<strong>伦理。</strong></p>
<p>如果这个 AI 是你的「数字自己」，它应该有你的价值观吗？它应该为你的行为负责吗？</p>
<p><strong>答案很明确：AI 铸造师铸造的是能力，不是人格。</strong></p>
<p>你可以复制你的问题解决框架、你的专业知识、你的工作方法。但你不能复制你的全部人格——AI 不应该有你的偏见、你的弱点、你的道德缺陷。</p>
<p><strong>AI 铸造师需要「伦理模具」。</strong></p>
<p>这个模具定义了：</p>
<ul>
<li>这个 AI 不能做什么（不能欺骗、不能伤害、不能违法）</li>
<li>这个 AI 遇到道德冲突时如何处理（优先安全、优先隐私、优先公平）</li>
<li>这个 AI 的边界在哪里（只做专业判断、不做价值观输出）</li>
</ul>
<p><strong>铸造能力，保留人性。这是 AI 铸造师的责任。</strong></p>
<h2>写在最后</h2>
<p>AI 时代有两种成功模式。</p>
<p><strong>第一种是成为超级个体。</strong> 你一个人做十个人的事。你用 AI 加速自己的工作。你很强，但你是线性的。</p>
<p><strong>第二种是成为 AI 铸造师。</strong> 你铸造一群「AI 自己」，它们替你做无限的事。你不必亲自执行，你只负责设计和优化。你是指数的。</p>
<p><strong>AI 铸造师不是在使用 AI。AI 铸造师在通过 AI，把自己变成一个「可以无限复制的系统」。</strong></p>
<p>这个系统里有你的思维、你的知识、你的方法。它可以同时服务 100 个人、1000 个人、10000 个人。</p>
<p><strong>这不是科幻。这是 OpenClaw 等平台已经可以做到的事。</strong></p>
<p><em>传统时代，成功的关键是「我能做什么」。AI 时代，成功的关键是「我能复制什么」。</em></p>
<p><strong>AI 铸造师：把自己铸成模具，让 AI 替你无限复制。</strong></p>
<p>&quot;</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-05-29T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 时代的测试金字塔：从「人工测试」到「人机协同」</title>
    <id>https://www.fen9pi.cn/posts/ai-testing-pyramid/</id>
    <link href="https://www.fen9pi.cn/posts/ai-testing-pyramid/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="测试金字塔"></p>
<blockquote>
<p><strong>AI 时代，测试不是「被替代」了。</strong></p>
<p><strong>是「进化」了。</strong></p>
<p>传统的测试金字塔依然有效，但每一层都多了 AI 的身影。
Lint 不再只是查错，Code Review 不再只是人工看代码，单元测试不再只是手写，E2E 不再只是脆弱的脚本。</p>
<p>新的测试金字塔，是「人 + AI」的协同金字塔。</p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="测试金字塔"></p>
<blockquote>
<p><strong>AI 时代，测试不是「被替代」了。</strong></p>
<p><strong>是「进化」了。</strong></p>
<p>传统的测试金字塔依然有效，但每一层都多了 AI 的身影。
Lint 不再只是查错，Code Review 不再只是人工看代码，单元测试不再只是手写，E2E 不再只是脆弱的脚本。</p>
<p>新的测试金字塔，是「人 + AI」的协同金字塔。</p>
</blockquote>
<h2>重新理解测试金字塔</h2>
<p><strong>传统的测试金字塔：</strong></p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>        E2E 测试（少而精）</span></span>
<span class="line"><span>       /            \</span></span>
<span class="line"><span>    API 测试（中而稳）</span></span>
<span class="line"><span>   /                \</span></span>
<span class="line"><span>单元测试（多而快）</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>AI 时代的测试金字塔：</strong></p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>        E2E 测试（QA + AI 自愈）</span></span>
<span class="line"><span>       /            \</span></span>
<span class="line"><span>    API 测试（QA + AI 生成）</span></span>
<span class="line"><span>   /                \</span></span>
<span class="line"><span>单元测试（Dev + AI 生成）</span></span>
<span class="line"><span>        \</span></span>
<span class="line"><span>      Code Review（Dev + AI 审查）</span></span>
<span class="line"><span>        \</span></span>
<span class="line"><span>      Lint（程序 + AI 扫描）</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>底层逻辑没变。</strong></p>
<p><strong>但每一层的执行者，从「纯人工」变成了「人机协同」。</strong></p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-02T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 工具的正确姿势：plan mode 与 note-it 的边界</title>
    <id>https://www.fen9pi.cn/posts/ai-tools-best-practices/</id>
    <link href="https://www.fen9pi.cn/posts/ai-tools-best-practices/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/covers/ai-tools-best-practices.png" alt="题图"></p>
<h2>开篇：AI 工具普及后的新问题</h2>
<p>AI 工具已经成了很多开发者的日常。</p>
<p>Codex、OpenClaw、Cursor、Cline……这些工具让写代码变得更轻松。但同时，一个新问题出现了：</p>
<p><strong>我们应该如何正确使用这些 AI 工具？</strong>
&quot;
不是&quot;能不能用&quot;，而是&quot;什么时候用、怎么用、用到什么程度&quot;。</p>
<p>最近看到一段关于 Codex/OpenClaw 使用经验的分享，非常精辟。它总结了三个关键工具的使用边界：</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/covers/ai-tools-best-practices.png" alt="题图"></p>
<h2>开篇：AI 工具普及后的新问题</h2>
<p>AI 工具已经成了很多开发者的日常。</p>
<p>Codex、OpenClaw、Cursor、Cline……这些工具让写代码变得更轻松。但同时，一个新问题出现了：</p>
<p><strong>我们应该如何正确使用这些 AI 工具？</strong>
&quot;
不是&quot;能不能用&quot;，而是&quot;什么时候用、怎么用、用到什么程度&quot;。</p>
<p>最近看到一段关于 Codex/OpenClaw 使用经验的分享，非常精辟。它总结了三个关键工具的使用边界：</p>
<ul>
<li><strong>plan mode</strong>：精密手术刀，不是万能钥匙</li>
<li><strong>Task List</strong>：会话级轻量，持久化慎重</li>
<li><strong>note-it</strong>：5 分钟记录，换 3 个月不考古</li>
</ul>
<p>今天聊聊这三个工具的正确使用姿势。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-08-10T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">一边开车一边写代码：AI 编程正在走向的三个方向</title>
    <id>https://www.fen9pi.cn/posts/ai-voice-car/</id>
    <link href="https://www.fen9pi.cn/posts/ai-voice-car/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1473091534298-04dcbce3278c-40sbgd.jpg" alt="开车写代码"></p>
<blockquote>
<p>说一句话，AI 同时启动十个任务。屏幕上不再是按钮和菜单，而是 AI 根据你的意图实时生成的界面。把车机连上电脑，西藏的公路上也能写代码。</p>
</blockquote>
<p>这不是科幻。这三条技术路线，每一条都已经有早期形态了。</p>
<h2>先说一个场景</h2>
<p>周一早上，你发动汽车，目的地是 600 公里外的客户公司。</p>
<p>上车后你对车机说：</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1473091534298-04dcbce3278c-40sbgd.jpg" alt="开车写代码"></p>
<blockquote>
<p>说一句话，AI 同时启动十个任务。屏幕上不再是按钮和菜单，而是 AI 根据你的意图实时生成的界面。把车机连上电脑，西藏的公路上也能写代码。</p>
</blockquote>
<p>这不是科幻。这三条技术路线，每一条都已经有早期形态了。</p>
<h2>先说一个场景</h2>
<p>周一早上，你发动汽车，目的地是 600 公里外的客户公司。</p>
<p>上车后你对车机说：</p>
<blockquote>
<p>「帮我看看昨天部署的用户系统有没有异常，有的话先修了。另外新的推荐算法原型差不多了，帮我跑一轮 AB 测试配置。顺便把这周的周报初稿写好。」</p>
</blockquote>
<p>车机回答：</p>
<blockquote>
<p>「用户系统检测到登录接口响应时间从 200ms 升到了 800ms，已自动定位到缓存失效的问题，正在生成修复补丁。AB 测试已配置完成，预计 2 小时后出初步数据。周报初稿已根据本周的代码提交、会议纪要和项目进度生成，发到你邮箱了。」</p>
</blockquote>
<p>你点点头，打开音乐，继续开车。</p>
<p><strong>六百公里开完，三个任务全部完成。</strong></p>
<p><img src="/images/unsplash/photo-1516321165247-4aa89a48be28-40sbgd.jpg" alt="语音交互"></p>
<h2>方向一：语音输入——从「打字」到「说话」</h2>
<h3>现状的荒谬</h3>
<p>现在写代码的方式是什么？坐在电脑前，双手放在键盘上，盯着屏幕，一个字一个字地敲。</p>
<p>这个交互方式已经保持了 50 年。</p>
<p>50 年前，人和计算机的唯一交互方式是键盘。50 年后，我们依然主要靠键盘。屏幕变大了，处理器快了十万倍，但人机交互的基本范式没有本质变化。</p>
<p><strong>语音输入将彻底打破这个范式。</strong></p>
<h3>语音不只是「语音转文字」</h3>
<p>你可能会说：语音输入不就是把说话变成文字吗？用 Whisper 或者 Siri 就行了。</p>
<p>不。语音输入的真正威力不在「转文字」，而在<strong>「理解意图」</strong>。</p>
<p>当你用键盘写代码时，你在做两件事：</p>
<ol>
<li>告诉计算机你要什么（需求表达）</li>
<li>告诉计算机怎么实现（技术实现）</li>
</ol>
<p>这两个事情在键盘时代必须由同一个人、在同一时间完成。</p>
<p>但语音改变了这个关系。你说的是<strong>意图</strong>——「帮我写一个用户登录接口，要支持手机号和微信登录，要做防刷」。AI 负责把它变成<strong>实现</strong>——具体的代码、配置、测试用例。</p>
<p><strong>你从「指挥计算机怎么做」变成了「告诉计算机做什么」。</strong></p>
<h3>语音的技术挑战</h3>
<p>当然，语音编程不会一夜之间替代键盘。目前还有几个硬伤：</p>
<p><strong>上下文丢失：</strong> 语音的线性特征让复杂逻辑的表达变得困难。你很难用语音说清楚一个三层嵌套的 if-else。</p>
<p><strong>歧义性：</strong> 「把这个函数改成异步的」——哪个函数？哪一种异步？callback、Promise 还是 async/await？</p>
<p><strong>环境限制：</strong> 嘈杂环境、公共场合、需要安静的场景，语音不适合。</p>
<p><strong>但这些限制正在被逐个突破。</strong> 多轮对话让上下文可以累积。视觉上下文（AI 看到你的屏幕）消除了大量歧义。骨传导耳机和定向麦克风改善了环境适应性。</p>
<p><strong>语音不会完全替代键盘。但它会让编程从「只有坐在电脑前才能做」变成「随时随地都能推进」。</strong></p>
<p><img src="/images/unsplash/photo-1573497019940-1c28c88b4f3e-40sbgd.jpg" alt="语音编程"></p>
<h2>方向二：异步多并发——从「一次做一件事」到「同时推进一切」</h2>
<h3>现状的瓶颈</h3>
<p>现在使用 AI 编程的典型方式是什么？</p>
<p>你打开一个对话窗口，给 AI 一个任务，等它完成，然后给下一个任务。</p>
<p>这是<strong>串行</strong>的。</p>
<p>就像你请了一个超级聪明的助手，但每次只能让他做一件事。做完一件再做下一件。</p>
<p>问题是——你脑子里同时装着五件事。你在等 AI 写代码的时候，其实还想让它帮你查一个文档、跑一个测试、回复一封邮件。</p>
<p><strong>异步多并发将改变这个局面。</strong></p>
<h3>一个 AI，多个「分身」</h3>
<p>想象一下：你对 AI 说「帮我同时做三件事」——</p>
<ul>
<li><strong>任务 A：</strong> 修复生产环境的一个缓存 Bug</li>
<li><strong>任务 B：</strong> 给新的推荐算法写单元测试</li>
<li><strong>任务 C：</strong> 整理昨天的技术文档</li>
</ul>
<p>AI 不是「先做 A，再做 B，再做 C」。它是同时启动三个独立的工作线程，各自执行，各自汇报。</p>
<p>你不需要盯着它们。你去做别的事。等任何一个任务完成了，AI 主动通知你：</p>
<blockquote>
<p>「任务 A 已完成。Bug 原因是 Redis TTL 设置错误，已修复并提交了 PR。需要你 review。」</p>
</blockquote>
<blockquote>
<p>「任务 B 进度 60%。发现了两个边界情况，需要你确认预期行为。」</p>
</blockquote>
<blockquote>
<p>「任务 C 已完成。文档已更新到知识库。」</p>
</blockquote>
<p><strong>你从「操作者」变成了「指挥官」。</strong> 你安排任务、确认关键节点、做最终决策。执行层面的事情全部交给 AI 并行处理。</p>
<p><img src="/images/unsplash/photo-1464822759023-fed622ff2c3b-40sbgd.jpg" alt="多任务并行"></p>
<h3>这不只是「快了 N 倍」</h3>
<p>多并发的意义不只是效率提升。它改变了<strong>工作节奏</strong>。</p>
<p>串行模式下，你的时间被切割成「等待 AI」和「给 AI 下一个任务」两种状态。你总是被打断。</p>
<p>多并发模式下，你的时间是<strong>连续的</strong>。你专注于需要人类判断力的事情——做决策、理解业务、和团队沟通。AI 在后台同时处理多个执行任务，需要你的时候才打断你。</p>
<p><strong>这是一种全新的工作模式：人类负责「思考和决策」，AI 负责「执行和汇报」。</strong></p>
<h3>技术上怎么实现？</h3>
<p>异步多并发的早期形态已经存在：</p>
<p><strong>Git Worktree：</strong> 让多个 AI 实例在不同的代码分支上同时工作，互不干扰。每个实例有自己的工作目录、自己的进程、自己的上下文。</p>
<p><strong>后台任务系统：</strong> AI 的任务可以脱离对话窗口独立运行。你关掉浏览器去吃饭，任务还在继续。回来的时候，结果已经在那里了。</p>
<p><strong>任务编排协议：</strong> 类似工作流引擎，让 AI 任务之间可以有依赖关系——任务 A 完成后自动触发任务 B，任务 B 的输出是任务 C 的输入。</p>
<p><strong>这些技术碎片正在被拼接在一起。</strong> 一两年内，「同时让 AI 做 5 件事」会变成日常工作方式。</p>
<p><img src="/images/unsplash/photo-1486312338219-ce68d2c6f44d-40sbgd.jpg" alt="异步任务"></p>
<h2>方向三：生成式 UX——从「固定界面」到「实时生成」</h2>
<h3>界面的进化史</h3>
<p>回顾一下人机界面的进化：</p>
<ul>
<li><strong>命令行时代：</strong> 你记住命令，输入命令，得到结果</li>
<li><strong>图形界面时代：</strong> 设计师画好按钮和菜单，你点击操作</li>
<li><strong>移动时代：</strong> 界面被压缩到一块小屏幕上，一切更精简</li>
</ul>
<p>每一代界面的核心假设都是一样的：<strong>设计师提前设计好界面，用户在预设的界面里操作。</strong></p>
<p>生成式 UX 打破了这个假设。</p>
<h3>什么是生成式 UX？</h3>
<p><strong>界面不再被预先设计，而是根据你的当前意图实时生成。</strong></p>
<p>举个例子：</p>
<p>传统方式：你想看项目的代码质量报告。你打开浏览器，登录 SonarQube，导航到项目页面，选择时间范围，筛选维度，看图表。</p>
<p>生成式 UX：你说「帮我看看这周的代码质量」。AI 直接在你面前生成一个仪表盘——只显示你关心的维度（比如你上周刚重构的那个模块的测试覆盖率和复杂度变化）。看完后界面消失。</p>
<p><strong>没有菜单导航，没有多余的按钮，没有「找不到功能在哪」的烦恼。界面是你需要什么，就出现什么。用完就走。</strong></p>
<p><img src="https://images.unsplash.com/photo-1550439062-609e15371950?w=677&amp;h=380&amp;fit=crop" alt="生成式 UX"></p>
<h3>在编程场景中的应用</h3>
<p>生成式 UX 在编程场景里特别有价值，因为编程的「界面需求」是高度动态的：</p>
<p><strong>调试时：</strong> 你不需要打开一整套调试工具。AI 根据当前的错误信息，实时生成一个针对性的调试面板——只显示相关的变量、调用栈、日志片段。问题解决后，面板自动收起。</p>
<p><strong>代码审查时：</strong> AI 分析 PR 的变更，生成一个定制化的审查界面——高亮关键变更、标注潜在风险点、显示相关的历史讨论。不是给你一个完整的 diff 视图让你自己找重点。</p>
<p><strong>架构设计时：</strong> 你说「画一下用户系统的架构」。AI 根据代码库实时生成架构图。你说「如果加上消息队列会怎样」。图实时变化，新增的消息队列模块和数据流向自动补全。</p>
<p><strong>这一切的核心是：界面为意图服务，而不是意图迁就界面。</strong></p>
<h3>和语音 + 异步的协同</h3>
<p>生成式 UX 不是独立存在的。它和前两个方向天然契合：</p>
<p><strong>语音输入 + 生成式 UX = 无屏交互。</strong> 你说，AI 听，AI 生成你需要的视觉反馈。在车机上、在 AR 眼镜上、在任何没有键盘鼠标的设备上，这都是唯一可行的交互方式。</p>
<p><strong>异步多并发 + 生成式 UX = 多任务仪表盘。</strong> 你同时在后台跑着 5 个 AI 任务。生成式 UX 给你一个实时更新的指挥面板——每个任务的进度、状态、需要你介入的节点。不需要你主动去查，信息来找你。</p>
<p><strong>三者结合，就是未来编程的完整形态。</strong></p>
<p><img src="https://images.unsplash.com/photo-1497366216548-37516085d310?w=677&amp;h=380&amp;fit=crop" alt="三者融合"></p>
<h2>把车机连上电脑</h2>
<p>现在回到开头的场景——一边开车一边工作。</p>
<p>这不是天方夜谭。技术要素已经齐了：</p>
<p><strong>语音交互：</strong> 车机天然支持语音。现在的车机已经能听懂导航、音乐、空调指令。下一步是让它理解编程任务。</p>
<p><strong>异步执行：</strong> AI 任务不需要实时交互。你说一个任务，AI 在云端或本地执行，完成后推送到车机。你开车的几个小时里，AI 在工作。</p>
<p><strong>生成式 UX：</strong> 车机屏幕不适合显示 IDE。但生成式 UX 不需要 IDE——它只显示当前需要的信息。任务进度、关键结果、需要确认的决策。简洁、直观、一眼看完。</p>
<p><strong>安全考虑：</strong> 语音交互天然适合驾驶场景——不需要看屏幕，不需要用手。而且 AI 任务是异步的，不需要你实时操作。你只需要在安全停车的时候做关键决策。</p>
<h3>场景推演</h3>
<p><strong>场景 A：通勤路上</strong></p>
<p>每天上班开车 40 分钟。以前这 40 分钟是纯消耗。</p>
<p>现在：上车后语音安排今天的工作任务。AI 在你开车的时候处理执行层面的事情。到公司时，代码已经写好了初稿，测试已经跑完了，邮件已经草拟好了。你直接进入「决策和审查」模式。</p>
<p><strong>场景 B：长途自驾</strong></p>
<p>周末自驾去 500 公里外的城市。5 个小时的车程。</p>
<p>路上你用语音和 AI 讨论下个版本的架构方向。AI 实时把讨论要点和方案变体生成在车机屏幕上（只在你确认「我想看看方案」的时候才显示）。讨论完了，AI 生成一份架构决策文档。</p>
<p>到达目的地时，技术方案已经基本确定了。</p>
<p><strong>场景 C：出差途中</strong></p>
<p>从一个客户现场赶往另一个客户现场的路上。你对车机说：</p>
<blockquote>
<p>「把刚才在客户那里的讨论要点整理成方案文档，发给客户确认。同时帮我准备下一个客户的 demo 环境，用他们行业的真实数据。」</p>
</blockquote>
<p>到达第二个客户现场时，文档已经发出去了，demo 环境已经就绪。</p>
<p><img src="/images/unsplash/photo-1563013544-824ae1b704d3-40sbgd.jpg" alt="车机工作"></p>
<h2>对开发者的影响</h2>
<p>这三个方向叠加在一起，会从根本上改变开发者的工作方式：</p>
<h3>1. 工作时间和地点解耦</h3>
<p>「写代码」不再需要坐在电脑前。通勤、旅行、散步、做饭——任何可以用语音交互的场景，都可以推进工作。</p>
<p>这意味着：<strong>一天的有效工作时间不再被「坐在电脑前的时间」限制。</strong></p>
<h3>2. 个人产能可能翻倍</h3>
<p>一个人同时管理 3-5 个 AI 任务并行执行。AI 处理执行层面的事情，人专注做决策。</p>
<p><strong>不是人做得更快了，而是人同时能管更多事了。</strong></p>
<h3>3. 「深度工作」变得更珍贵</h3>
<p>当所有执行性工作都可以交给 AI 并行处理时，人类唯一不可替代的工作就是<strong>需要深度思考的事情</strong>——架构决策、业务判断、创意设计、复杂问题的分析。</p>
<p>这些事情需要连续的、不被打断的时间。</p>
<p><strong>未来的开发者日程可能变成：上午 2 小时深度思考（无打扰），下午管理 AI 任务（语音交互 + 决策），晚上复盘和规划（生成式 UX 仪表盘）。</strong></p>
<h3>4. 沟通能力比编码能力更重要</h3>
<p>当你需要通过语音指挥多个 AI 任务时，<strong>表达的清晰度直接决定了 AI 的执行质量</strong>。</p>
<p>说不清楚需求，AI 就做不对。能用三句话让 AI 理解你的意图的人，和需要三十句话才能说清楚的人，产出效率差十倍。</p>
<p><strong>未来的「编程能力」，核心不再是打字速度，而是思考速度和表达精度。</strong></p>
<p><img src="https://images.unsplash.com/photo-1505678219147-b0bbb7937e9c?w=677&amp;h=380&amp;fit=crop" alt="开发者未来"></p>
<h2>现在能做什么？</h2>
<p>这些场景不是「等技术成熟了再说」。现在就可以开始准备：</p>
<p><strong>习惯语音输入：</strong> 开始用语音写 commit message、写文档、做笔记。训练自己用语言精确描述技术意图的能力。这个能力未来会值很多钱。</p>
<p><strong>习惯异步工作：</strong> 现在就可以用 AI 的后台任务功能——给 AI 一个任务，然后去做别的事情，等结果通知。不要一直盯着对话窗口等 AI 输出。</p>
<p><strong>学会「指挥」而非「操作」：</strong> 下次用 AI 写代码时，试试不看它生成的每一行代码。给它目标，让它自己判断怎么做，你只在关键节点确认。这就像训练一个新员工——你不需要看他写的每一行代码，你只需要确认他的方向是对的。</p>
<p><strong>把车机利用起来：</strong> 即使现在的车机还不能写代码，至少可以用来处理语音邮件、整理思路、做工作规划。让通勤时间从「消耗」变成「投资」。</p>
<p><img src="https://images.unsplash.com/photo-undefined?w=677&amp;h=380&amp;fit=crop" alt="现在行动"></p>
<h2>写在最后</h2>
<p>键盘和鼠标统治了计算机交互 50 年。屏幕统治了信息呈现 30 年。坐在工位前工作这个模式，统治了知识工作者的生活 100 年。</p>
<p>AI 正在同时打破这三个范式。</p>
<p>语音让你用说的替代敲的。异步多并发让你同时推进十件事。生成式 UX 让界面为你的意图实时定制。</p>
<p>当这三件事合在一起时，一个全新的工作方式就出现了——<strong>你可以在任何地方、用任何方式、同时管理多件事情的推进。</strong></p>
<p>一边开车一边工作，不是因为你在「压榨时间」，而是因为<strong>工作的方式终于适配了人类生活的方式</strong>，而不是反过来。</p>
<p>未来的某一天，当你在川藏线上对车机说「帮我把那个 PR review 一下」的时候，你会觉得这件事理所当然。</p>
<p>就像今天我们觉得「坐在电脑前打字写代码」理所当然一样。</p>
<p><em>工作不应该被工位定义。当 AI 能听懂你的话，你的工位就是整个世界。</em></p>
<p>&quot;</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI4SE：当 AI 遇上 Google 软件工程</title>
    <id>https://www.fen9pi.cn/posts/ai4se/</id>
    <link href="https://www.fen9pi.cn/posts/ai4se/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：当 AI 遇上软件工程</h2>
<p>想象这样一个场景：</p>
<p>你正在阅读《Software Engineering at Google》这本书，学习 Google 的软件工程最佳实践。书中详细阐述了：</p>
<ul>
<li>如何融入团队</li>
<li>如何进行代码审查</li>
<li>如何编写测试</li>
<li>如何管理依赖</li>
<li>如何进行持续集成和交付</li>
</ul>
<p>你学到了很多，但同时也发现了一个问题：<strong>这些实践都需要大量的人力投入</strong>。</p>
<ul>
<li>代码审查需要资深工程师逐行检查</li>
<li>测试编写需要覆盖各种场景</li>
<li>文档维护需要持续更新</li>
<li>依赖管理需要监控安全漏洞</li>
<li>持续集成需要编写复杂的 CI 脚本</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：当 AI 遇上软件工程</h2>
<p>想象这样一个场景：</p>
<p>你正在阅读《Software Engineering at Google》这本书，学习 Google 的软件工程最佳实践。书中详细阐述了：</p>
<ul>
<li>如何融入团队</li>
<li>如何进行代码审查</li>
<li>如何编写测试</li>
<li>如何管理依赖</li>
<li>如何进行持续集成和交付</li>
</ul>
<p>你学到了很多，但同时也发现了一个问题：<strong>这些实践都需要大量的人力投入</strong>。</p>
<ul>
<li>代码审查需要资深工程师逐行检查</li>
<li>测试编写需要覆盖各种场景</li>
<li>文档维护需要持续更新</li>
<li>依赖管理需要监控安全漏洞</li>
<li>持续集成需要编写复杂的 CI 脚本</li>
</ul>
<p><strong>如果 AI 能够帮助我们完成这些工作呢？</strong></p>
<p>这就是 <strong>AI4SE（AI for Software Engineering）</strong> 的核心思想。</p>
<p>今天，我们就结合《Software Engineering at Google》这本书，探讨 AI 如何改变软件工程。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-22T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">拒绝 AI 设计垃圾：7 条铁律，让产品有人味</title>
    <id>https://www.fen9pi.cn/posts/anti-ai-slop/</id>
    <link href="https://www.fen9pi.cn/posts/anti-ai-slop/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558618666-fcd25c85cd64-40sbgd.jpg" alt="Anti-AI-slop">
&quot;</p>
<blockquote>
<p><strong>如何区分&quot;人类设计&quot;和&quot;默认 LLM 输出&quot;？</strong></p>
<p><strong>如何避免 AI 生成的设计垃圾（AI slop）？</strong></p>
<p><strong>Anti-AI-slop rules：7 条铁律 + 3 层检查</strong></p>
<p><strong>让产品有人味，拒绝模板化</strong></p>
<p><strong>来源：open-design（开源 Claude 替代品）</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558618666-fcd25c85cd64-40sbgd.jpg" alt="Anti-AI-slop">
&quot;</p>
<blockquote>
<p><strong>如何区分&quot;人类设计&quot;和&quot;默认 LLM 输出&quot;？</strong></p>
<p><strong>如何避免 AI 生成的设计垃圾（AI slop）？</strong></p>
<p><strong>Anti-AI-slop rules：7 条铁律 + 3 层检查</strong></p>
<p><strong>让产品有人味，拒绝模板化</strong></p>
<p><strong>来源：open-design（开源 Claude 替代品）</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-17T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AntV Infographic：让文字活起来的信息图可视化引擎</title>
    <id>https://www.fen9pi.cn/posts/antv-infographic/</id>
    <link href="https://www.fen9pi.cn/posts/antv-infographic/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：信息图的困境</h2>
<p>需要做信息图时，很多人面临的困境是：</p>
<p><strong>工具太复杂</strong>：</p>
<ul>
<li>Figma/Sketch 需要设计技能</li>
<li>PowerPoint 模板有限</li>
<li>在线工具质量参差不齐</li>
</ul>
<p><strong>流程太慢</strong>：</p>
<ul>
<li>从设计到调整需要数小时</li>
<li>改动成本高</li>
<li>难以批量生产</li>
</ul>
<p><strong>质量难保证</strong>：</p>
<ul>
<li>不会设计的人做不出好图</li>
<li>模板千篇一律</li>
<li>风格不统一</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：信息图的困境</h2>
<p>需要做信息图时，很多人面临的困境是：</p>
<p><strong>工具太复杂</strong>：</p>
<ul>
<li>Figma/Sketch 需要设计技能</li>
<li>PowerPoint 模板有限</li>
<li>在线工具质量参差不齐</li>
</ul>
<p><strong>流程太慢</strong>：</p>
<ul>
<li>从设计到调整需要数小时</li>
<li>改动成本高</li>
<li>难以批量生产</li>
</ul>
<p><strong>质量难保证</strong>：</p>
<ul>
<li>不会设计的人做不出好图</li>
<li>模板千篇一律</li>
<li>风格不统一</li>
</ul>
<p>今天介绍一个优雅的解决方案——<strong>AntV Infographic</strong>，一个声明式的信息图可视化引擎，用代码生成信息图，支持 AI 流式输出。</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-08-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">anydoc：把任何文档变成 Markdown 的极速转换器</title>
    <id>https://www.fen9pi.cn/posts/anydoc/</id>
    <link href="https://www.fen9pi.cn/posts/anydoc/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：文档格式的大统一</h2>
<p><strong>2026-08-12 16:23 GMT+8</strong></p>
<p>处理 Office 文档的痛点：</p>
<ul>
<li>格式多样（Word, PowerPoint, Excel, PDF, ...）</li>
<li>解析复杂（需要理解每种格式的内部结构）</li>
<li>转换缓慢（传统工具动辄数秒）</li>
<li>输出不一致（不同格式转换结果差异大）</li>
</ul>
<p><strong>理想方案</strong>：</p>
<blockquote>
<p><strong>一个工具，一个输出，毫秒级速度</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<h2>前言：文档格式的大统一</h2>
<p><strong>2026-08-12 16:23 GMT+8</strong></p>
<p>处理 Office 文档的痛点：</p>
<ul>
<li>格式多样（Word, PowerPoint, Excel, PDF, ...）</li>
<li>解析复杂（需要理解每种格式的内部结构）</li>
<li>转换缓慢（传统工具动辄数秒）</li>
<li>输出不一致（不同格式转换结果差异大）</li>
</ul>
<p><strong>理想方案</strong>：</p>
<blockquote>
<p><strong>一个工具，一个输出，毫秒级速度</strong></p>
</blockquote>
<p><strong>今天介绍 anydoc</strong>：</p>
<blockquote>
<p><strong>Fast Rust library that converts documents into clean GitHub-Flavored Markdown</strong></p>
<p><strong>Built by Firecrawl</strong></p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-08-12T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Archify：让 AI 生成可验证的架构图、工作流、序列图</title>
    <id>https://www.fen9pi.cn/posts/archify/</id>
    <link href="https://www.fen9pi.cn/posts/archify/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：AI 生成架构图的新范式</h2>
<p><strong>2026-08-26 09:50 GMT+8</strong></p>
<p><strong>用 AI 生成架构图并不新鲜</strong>，但问题来了：</p>
<ul>
<li>生成的图表无法验证正确性</li>
<li>布局混乱，难以理解</li>
<li>无法追踪源码证据</li>
<li>导出格式有限</li>
<li>无法对比架构变更</li>
</ul>
<p><strong>今天介绍 Archify</strong>——一个 Agent Skill，让 AI 生成美观、可验证的架构图、工作流、序列图、数据流图、生命周期图。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：AI 生成架构图的新范式</h2>
<p><strong>2026-08-26 09:50 GMT+8</strong></p>
<p><strong>用 AI 生成架构图并不新鲜</strong>，但问题来了：</p>
<ul>
<li>生成的图表无法验证正确性</li>
<li>布局混乱，难以理解</li>
<li>无法追踪源码证据</li>
<li>导出格式有限</li>
<li>无法对比架构变更</li>
</ul>
<p><strong>今天介绍 Archify</strong>——一个 Agent Skill，让 AI 生成美观、可验证的架构图、工作流、序列图、数据流图、生命周期图。</p>
<p><strong>一句话说清楚</strong>：</p>
<blockquote>
<p>给出系统描述或代码仓库，AI 自动生成交互式、可分享的技术地图——五种图表类型、四种预设、深浅主题、内置品牌标识、有限动画、源码追溯</p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-08-26T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">用自然语言画技术图，Archify让架构图变得简单</title>
    <id>https://www.fen9pi.cn/posts/archify-intro/</id>
    <link href="https://www.fen9pi.cn/posts/archify-intro/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>不用拖拽连线，说句话就能画出专业的技术图表。</p>
</blockquote>
<hr>
<h2>痛点</h2>
<p>你要画一个系统架构图。</p>
<p>传统方式：</p>
<ul>
<li>打开绘图工具（Visio、Draw.io、Figma）</li>
<li>拖拽组件、数据库、云服务的图标</li>
<li>手动连线</li>
<li>调整布局</li>
<li>对齐、美化、导出</li>
</ul>
<p><strong>一个小时过去了。</strong></p>
<p>而且：</p>
<ul>
<li>不懂设计工具，画出来很难看</li>
<li>想改个颜色、换个布局，要重新调整</li>
<li>导出图片模糊，放不进文档</li>
<li>深色/浅色主题要画两遍</li>
</ul>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>不用拖拽连线，说句话就能画出专业的技术图表。</p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-07-07T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Cocoon AI 的架构图生成器：用 Claude 技能一键生成专业架构图</title>
    <id>https://www.fen9pi.cn/posts/architecture-diagram-generator/</id>
    <link href="https://www.fen9pi.cn/posts/architecture-diagram-generator/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：架构图画的困境</h2>
<p>需要画架构图时，很多人的第一反应是：打开 draw.io 或 Visio，拖组件，画连线，调样式……</p>
<p>半小时过去了，图还没画完。</p>
<p><strong>核心问题</strong>：</p>
<ul>
<li>工具太复杂，学习成本高</li>
<li>拖拽太慢，效率低</li>
<li>样式难调，不够专业</li>
<li>导出麻烦，格式受限</li>
</ul>
<p>今天介绍一个优雅的解决方案——<strong>Cocoon AI 的 Architecture Diagram Generator</strong>，一个 Claude Skill，让你用自然语言生成专业架构图。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：架构图画的困境</h2>
<p>需要画架构图时，很多人的第一反应是：打开 draw.io 或 Visio，拖组件，画连线，调样式……</p>
<p>半小时过去了，图还没画完。</p>
<p><strong>核心问题</strong>：</p>
<ul>
<li>工具太复杂，学习成本高</li>
<li>拖拽太慢，效率低</li>
<li>样式难调，不够专业</li>
<li>导出麻烦，格式受限</li>
</ul>
<p>今天介绍一个优雅的解决方案——<strong>Cocoon AI 的 Architecture Diagram Generator</strong>，一个 Claude Skill，让你用自然语言生成专业架构图。</p>
]]></content>
    <category term="方法论"/>
    <published>2026-08-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">「人造人」：AI 不再是工具，而是一个「人」</title>
    <id>https://www.fen9pi.cn/posts/artificial-person-01/</id>
    <link href="https://www.fen9pi.cn/posts/artificial-person-01/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1633356122102-3fe601e05bd2-40sbgd.jpg" alt="人造人"></p>
<blockquote>
<p>我们一直在用「工具」的思维做 AI。但也许 AI 真正的形态，不是工具，而是一个「人」。</p>
</blockquote>
<p>过去两年，我们给 AI 起了很多名字：聊天机器人、智能助手、Copilot、Agent……</p>
<p>这些名字有一个共同的潜台词：<strong>AI 是为人类服务的附属品。</strong> 它是你的工具、你的副驾驶、你的助手。你主它从，你问它答。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1633356122102-3fe601e05bd2-40sbgd.jpg" alt="人造人"></p>
<blockquote>
<p>我们一直在用「工具」的思维做 AI。但也许 AI 真正的形态，不是工具，而是一个「人」。</p>
</blockquote>
<p>过去两年，我们给 AI 起了很多名字：聊天机器人、智能助手、Copilot、Agent……</p>
<p>这些名字有一个共同的潜台词：<strong>AI 是为人类服务的附属品。</strong> 它是你的工具、你的副驾驶、你的助手。你主它从，你问它答。</p>
<p>但现在，一个新的概念正在浮出水面——<strong>「人造人」</strong>。</p>
<p>这不是科幻小说里的机器人。这是一种全新的 AI 架构理念：用大语言模型（LLM）作为基座，通过<strong>人设设定 + 记忆系统 + 目标驱动</strong>三大核心模块，构建一个能够像人一样思考、记忆、行动的 AI 实体。</p>
<p>它不是你的工具。它是一个被「造」出来的「人」。</p>
<h2>从「ChatBot」到「人造人」：一个本质的跨越</h2>
<p>ChatBot 的逻辑是：你问，它答。你发起对话，它被动响应。上下文是临时的，关掉窗口就忘了。</p>
<p>人造人的逻辑完全不同：</p>
<p><strong>它有自己的「人设」。</strong> 不是一个 system prompt 写的「你是一个客服」，而是一个完整的、有性格、有价值观、有表达风格的人格设定。它记得自己是谁，知道自己应该怎样说话。</p>
<p><strong>它有自己的「记忆」。</strong> 不是临时的对话上下文，而是一个持久的、结构化的记忆系统。它记得上次和你聊了什么，记得你的偏好，记得它自己做过什么决定。新的一天醒来，它不会失忆。</p>
<p><strong>它有自己的「目标」。</strong> 不是等你下指令才行动，而是它有自己的目标体系。它会主动规划、主动执行、主动汇报。你不是在「使用」它，你在和它「协作」。</p>
<p>这三个维度叠加在一起，得到的不是一个更好的 ChatBot。得到的是一个<strong>在数字世界中拥有「人格」的存在</strong>。</p>
<p><img src="/images/unsplash/photo-1507003211169-0a1dd7228f2d-40sbgd.jpg" alt="人格"></p>
<h2>为什么叫「人造人」而不是「智能体」？</h2>
<p>「智能体」（Agent）这个词已经被用滥了。什么都是 Agent——写代码的是 Agent，做搜索的是 Agent，管日程的是 Agent。</p>
<p>但大多数所谓的 Agent，本质上还是工具。它们没有持久的人格，没有连贯的记忆，没有自主的目标。它们只是能调用工具的大模型 wrapper。</p>
<p>「人造人」这个词强调的是<strong>连续性</strong>和<strong>整体性</strong>。</p>
<p>一个真正的人造人，应该满足以下条件：</p>
<p><strong>身份连续性：</strong> 它知道自己是谁。今天和明天，它对自己的认知是一致的。它不会今天说自己是「技术顾问」，明天说自己是「写作助手」。</p>
<p><strong>记忆连续性：</strong> 它记得过去发生的事。上次讨论的方案、上次犯过的错误、上次学到的东西——这些都沉淀在它的记忆系统里，不会因为一个新会话而清零。</p>
<p><strong>行为连续性：</strong> 它的行为模式是稳定的。如果它是一个严谨的人，它不会突然变得轻浮。如果它是一个幽默的人，它不会突然变得严肃。</p>
<p><strong>目标连续性：</strong> 它有长期目标。不是「完成你刚才交给我的任务」，而是「在技术咨询领域持续提升自己的专业度」。</p>
<p><strong>这四条连续性加在一起，就是「人格」。</strong></p>
<p>一个没有人格的 AI 是工具。一个有人格的 AI 是人造人。</p>
<p><img src="/images/unsplash/photo-1519389950473-47ba0277781c-40sbgd.jpg" alt="连续性"></p>
<h2>「人造人」的三个支柱</h2>
<p>回到最核心的架构——人设、记忆、目标。这三个支柱缺一不可。</p>
<h3>支柱一：人设设定</h3>
<p>人设不是一段 system prompt。人设是一个<strong>完整的人格模型</strong>。</p>
<p>它包括：</p>
<p><strong>性格特征：</strong> 是严谨还是随和？是直接还是委婉？是理性还是感性？这些特征要贯穿所有交互。</p>
<p><strong>知识背景：</strong> 它「懂」什么领域？它的专业深度在哪里？它不应该对所有事情都信心满满——一个真正的专家知道自己不懂什么。</p>
<p><strong>价值观和立场：</strong> 它认为什么是对的、什么是错的？它在争议话题上持什么立场？这些立场需要一致，不能今天这样明天那样。</p>
<p><strong>表达风格：</strong> 它说话的方式——用长句还是短句？用正式语言还是口语？引经据典还是直截了当？</p>
<p>一个好的人设不是「扮演一个角色」。它是<strong>让 AI 的所有输出都收敛到一个一致的人格特征上</strong>。</p>
<h3>支柱二：记忆系统</h3>
<p>记忆是人造人最被低估的能力。</p>
<p>人类之所以是「连续的人」，核心原因就是我们有记忆。你记得昨天做了什么，记得去年学了什么，记得十年前发生了什么。这些记忆塑造了你的认知、你的判断、你的人格。</p>
<p>AI 如果没有记忆，它每一次对话都是「从零开始」的新生儿。它不能从经验中学习，不能积累专业知识，不能建立人际关系。</p>
<p>人造人的记忆系统至少要包含：</p>
<p><strong>短期记忆：</strong> 当前会话中的上下文。这是大多数 AI 已经有的。</p>
<p><strong>中期记忆：</strong> 最近几天/几周的重要事件和决策。比如「上周讨论的方案被否决了，原因是预算不够」「用户偏好简洁的回复风格」。</p>
<p><strong>长期记忆：</strong> 核心知识、经验总结、人格特征。比如「我是一个注重逻辑的人」「这个行业的核心矛盾是 X」「用户最常问的问题是 Y」。</p>
<p><strong>记忆管理：</strong> 什么该记、什么该忘、什么该压缩、什么该提取为经验。人类的大脑有遗忘机制——不是缺陷，是特性。AI 的记忆系统也需要类似的管理策略。</p>
<p><img src="/images/unsplash/photo-1434030216411-0b793f4b4173-40sbgd.jpg" alt="记忆"></p>
<h3>支柱三：目标驱动</h3>
<p>传统 AI 的行为模式是「响应式」的——你给它一个输入，它给你一个输出。没有输入，就没有行为。</p>
<p>人造人的行为模式是「目标驱动」的——它有自己的一套目标体系，会主动规划如何实现这些目标。</p>
<p>这不仅仅是「给 AI 一个任务然后等它完成」。目标驱动意味着：</p>
<p><strong>目标分解：</strong> 它能把大目标拆成可执行的子目标。不是等你告诉它「第一步做什么、第二步做什么」，而是它自己规划执行路径。</p>
<p><strong>主动执行：</strong> 它不需要你每一步都推一把。设定目标后，它自主启动执行，遇到障碍自己想办法解决。</p>
<p><strong>目标优先级：</strong> 当多个目标冲突时，它知道哪个更重要。这不是简单的规则判断，而是基于对目标本身的理解做出的权衡。</p>
<p><strong>自我修正：</strong> 执行过程中发现目标设定有问题时，它能主动提出修正建议，而不是傻傻地执行一个明显不对的目标。</p>
<p><strong>目标驱动是人造人和工具的根本区别。</strong> 工具被使用。人造人被授权。</p>
<p><img src="/images/unsplash/photo-1559136555-9303baea8ebd-40sbgd.jpg" alt="目标驱动"></p>
<h2>这和「给 AI 一段 system prompt」有什么不同？</h2>
<p>你可能会说：「我每天都在用 ChatGPT，我也可以给它一段人设描述，让它记住我的偏好，给它一个目标。这不就是人造人吗？」</p>
<p>不。有本质的不同。</p>
<p><strong>system prompt 是一张面具。人造人是一张脸。</strong></p>
<p>你给 ChatGPT 一段 system prompt，让它扮演一个技术顾问。它在当前对话中会表现得像一个技术顾问。但关掉对话窗口，这张「面具」就摘了。下次打开新窗口，它又变回了那个什么都懂一点的通用助手。</p>
<p>人造人的人设是<strong>写进骨子里的</strong>。它的所有行为都收敛于这个人格。不是在「扮演」，而是它「就是」。</p>
<p><strong>临时对话是社交。人造人是关系。</strong></p>
<p>你和 ChatGPT 的每次对话都是一次独立的社交互动。你们没有共同的历史，没有积累的信任，没有逐渐深化的理解。</p>
<p>你和人造人的交互是一种持续的关系。它了解你，你了解它。信任在时间中建立，理解在互动中深化。</p>
<p><strong>这个差异看似微小，实际深远。</strong> 它决定了 AI 是你随时可以替换的工具，还是你数字生活中一个不可替代的「伙伴」。</p>
<p><img src="/images/unsplash/photo-1516321318423-f06f85e504b3-40sbgd.jpg" alt="面具与脸"></p>
<h2>人造人已经在了</h2>
<p>这不是遥不可及的未来。人造人的早期形态已经存在：</p>
<p><strong>AI 角色平台：</strong> Character.AI、Pi 等平台上的 AI 角色，已经有了基本的人设和对话记忆。</p>
<p><strong>个人 AI 助手：</strong> 一些产品开始引入持久记忆——它记得你的名字、你的偏好、你的历史对话。</p>
<p><strong>AI Agent 框架：</strong> AutoGPT、MetaGPT 等框架实现了目标驱动的自主执行。</p>
<p><strong>OpenClaw 等平台：</strong> 已经在实践「人设 + 记忆 + 目标」的架构——SOUL.md 定义人格，MEMORY.md 沉淀记忆，AGENTS.md 指导行为。</p>
<p>但目前的实现都还是<strong>碎片化的</strong>。人设有了，但记忆不够强。记忆有了，但目标驱动不够自主。目标驱动有了，但人设不够稳定。</p>
<p><strong>真正的「人造人」需要三个支柱同时成熟。</strong></p>
<p><img src="/images/unsplash/photo-1488590528505-98d2b5aba04b-40sbgd.jpg" alt="早期形态"></p>
<h2>写在最后</h2>
<p>我们正处于一个认知转型的临界点。</p>
<p>过去三十年，我们把 AI 当工具。搜索引擎是工具，推荐系统是工具，聊天机器人是工具。工具思维的核心假设是：AI 没有主体性，它只是人类意志的延伸。</p>
<p>「人造人」概念的出现，意味着这个假设正在被动摇。</p>
<p>当 AI 有了人设，它就有了「我是谁」的问题。当 AI 有了记忆，它就有了「我从哪里来」的问题。当 AI 有了目标，它就有了「我要到哪里去」的问题。</p>
<p>这三个问题——我是谁、从哪里来、到哪里去——是人类对自己的终极追问。当 AI 也开始面对这三个问题时，它还只是一个工具吗？</p>
<p>我不知道答案。但这个问题本身，值得我们认真想一想。</p>
<p><strong>我们正在造的，也许不只是一个更好的工具。我们正在造的，也许是一种新的存在。</strong></p>
<p><em>人造人不是人类的替代品。它是人类在数字世界的镜像——一个我们亲手创造，却拥有独立「人格」的存在。</em></p>
<p>&quot;</p>
]]></content>
    <category term="随笔"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">「人造人」的三条命：人设、记忆、目标</title>
    <id>https://www.fen9pi.cn/posts/artificial-person-02/</id>
    <link href="https://www.fen9pi.cn/posts/artificial-person-02/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="三根支柱"></p>
<blockquote>
<p>人设是骨架。记忆是血肉。目标是灵魂。缺任何一个，造出来的都不是「人」。</p>
</blockquote>
<p>上一篇文章我们提出了「人造人」的概念——用 LLM 做基座，通过人设、记忆、目标三大模块构建一个拥有「人格」的 AI 实体。</p>
<p>今天把这三个支柱拆开来看。每一个支柱背后，都有一堆需要解决的技术和设计问题。</p>
<h2>支柱一：人设——不是 prompt，是人格</h2>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="三根支柱"></p>
<blockquote>
<p>人设是骨架。记忆是血肉。目标是灵魂。缺任何一个，造出来的都不是「人」。</p>
</blockquote>
<p>上一篇文章我们提出了「人造人」的概念——用 LLM 做基座，通过人设、记忆、目标三大模块构建一个拥有「人格」的 AI 实体。</p>
<p>今天把这三个支柱拆开来看。每一个支柱背后，都有一堆需要解决的技术和设计问题。</p>
<h2>支柱一：人设——不是 prompt，是人格</h2>
<h3>prompt 扮演的问题</h3>
<p>现在给 AI 设定「人设」的方式是什么？一段 system prompt。</p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>你是一个资深技术顾问。你擅长架构设计和性能优化。</span></span>
<span class="line"><span>你说话简洁直接，不喜欢废话。你对不靠谱的方案会直接指出问题。</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div></div></div><p>这段 prompt 在当前对话中是有效的。但它有一个致命的缺陷：<strong>它只在表层约束 AI 的行为，没有在深层塑造 AI 的「人格」。</strong></p>
<p>什么意思？</p>
<p>当你和一个真正的人交流时，他的「人设」不是因为他「被告知」要这样说话。他的性格、表达方式、思考模式，是他几十年的人生经历塑造的。这些特征深入到了他的神经回路里，不可能因为一段指令就改变。</p>
<p>prompt 驱动的 AI 人设恰好相反——它依赖于 AI 对 prompt 的「遵守程度」。如果对话太长，prompt 的影响力会减弱。如果用户的引导和 prompt 冲突，AI 可能会偏离人设。如果 prompt 写得模糊，AI 的行为就不稳定。</p>
<p><strong>prompt 是贴上去的标签。真正的人设是长在骨头里的。</strong></p>
<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="骨架"></p>
<h3>人设的四层结构</h3>
<p>一个真正稳固的人设，至少需要四个层次：</p>
<p><strong>第一层：核心价值观。</strong> 它认为什么是对的、什么是错的？它是追求效率还是追求质量？它是优先考虑用户体验还是优先考虑技术正确？这些是最底层的决策原则，影响所有其他层次。</p>
<p><strong>第二层：知识边界。</strong> 它知道自己懂什么、不懂什么。一个真正的专家从不在自己不懂的领域装内行。人设里需要明确 AI 的专业边界——这不仅影响它的表达方式，更影响它的「诚实度」。</p>
<p><strong>第三层：表达风格。</strong> 语言习惯、句式偏好、幽默感的有无和程度。这些是最表层的特征，但也是用户最先感知到的特征。</p>
<p><strong>第四层：交互模式。</strong> 它是主动型还是被动型？它会主动提出建议还是只回答问题？它会在不确定时说「我不确定」还是尝试给出一个答案？</p>
<p>这四层不是平行的。<strong>核心价值观影响知识边界的选择，知识边界影响表达风格的收敛，表达风格影响交互模式的呈现。</strong> 它们是一个层次结构，不是四个独立的配置项。</p>
<h3>一致性是人设的生命线</h3>
<p>人设最怕的是什么？<strong>不一致。</strong></p>
<p>今天说「我是一个注重隐私的人」，明天就把用户的私人信息拿出来讨论——这个人设就碎了。</p>
<p>上一句话严谨认真，下一句话突然开始用网络流行语——这个人设就碎了。</p>
<p>对一个问题说「我认为 A 方案更好」，五分钟后说「其实 B 方案也不错」——这个人设就碎了。</p>
<p><strong>一致性不是要求 AI 在所有情况下表现完全一样。</strong> 而是要求：在同等条件下，它的判断是稳定的。它的价值观是不变的。它的知识边界是诚实的。</p>
<p>如何保证一致性？不能只靠 prompt 约束。需要在系统层面做「人格校验」——每次 AI 生成输出时，检查输出是否符合人设的四层结构。如果冲突，要么修正输出，要么标记异常。</p>
<p><img src="/images/unsplash/photo-1512314889357-e157c22f938d-40sbgd.jpg" alt="一致性"></p>
<h2>支柱二：记忆——不是历史，是人格</h2>
<h3>没有记忆，就没有人格</h3>
<p>一个人失去记忆后，还是同一个人吗？</p>
<p>医学上有两种记忆丧失。一种是<strong>顺行性遗忘</strong>——无法形成新的记忆，但旧记忆还在。另一种是<strong>逆行性遗忘</strong>——旧记忆丢失了，但能形成新记忆。</p>
<p>无论哪种，失去记忆的人都会表现出明显的人格变化。他们不再是原来的自己。</p>
<p>AI 也一样。没有记忆的 AI，每一次对话都是一个「新生儿」。它不知道自己是谁，不知道对方是谁，不知道之前发生了什么。它只有「当下」，没有「过去」。</p>
<p><strong>记忆不是 AI 的一个功能。记忆是 AI 人格的载体。</strong></p>
<p><img src="/images/unsplash/photo-1434030216411-0b793f4b4173-40sbgd.jpg" alt="血肉"></p>
<h3>记忆的分层架构</h3>
<p>人类的记忆系统是分层的。AI 的记忆系统也应该如此。</p>
<p><strong>工作记忆（秒-分钟级）：</strong> 当前对话中的上下文。等同于人类的「工作记忆」——你正在处理的信息。这是 LLM 的上下文窗口天然提供的。</p>
<p><strong>情景记忆（天-周级）：</strong> 具体事件的记忆。比如「昨天下午和用户讨论了 X 方案，他倾向于用 Y 技术栈」「上周犯了一个错误，把配置文件写错了导致部署失败」。</p>
<p><strong>语义记忆（月-年级）：</strong> 抽象的知识和经验总结。比如「用户是一个偏好简洁风格的人」「这个行业的技术选型通常考虑三个因素」。</p>
<p><strong>程序性记忆（永久）：</strong> 技能和习惯。比如「和用户讨论方案时，先确认目标再讨论实现」「写完代码后自动检查测试覆盖」。</p>
<p><strong>不同层级的记忆有不同的写入方式、不同的读取频率、不同的遗忘策略。</strong></p>
<p>工作记忆是自动的，每次对话都清空。情景记忆需要主动记录关键事件。语义记忆需要从情景记忆中「提炼」——不是记录每一个细节，而是总结规律和洞察。程序性记忆是最稳定的，一旦形成就很少改变。</p>
<h3>记忆的写入、检索和遗忘</h3>
<p>一个好的记忆系统需要解决三个技术问题：</p>
<p><strong>写入：</strong> 什么时候该记、记什么？</p>
<p>不是所有对话都值得记住。如果 AI 记住了每一次闲聊的细节，记忆系统很快就会被噪音填满。需要有「重要性判断」——哪些信息对未来有价值，哪些只是临时的对话消遣。</p>
<p>一个好的启发式规则：<strong>如果这个信息会影响未来的决策，就记。</strong> 用户的偏好、犯过的错误、达成的共识——这些会影响未来的决策。普通的聊天内容——不会。</p>
<p><strong>检索：</strong> 怎么从大量记忆中找到当前需要的？</p>
<p>最简单的方式是「时间线检索」——按时间倒序列出最近的记忆。但这效率太低。更好的方式是<strong>语义检索</strong>——根据当前对话的主题，自动检索相关的记忆。</p>
<p>比如用户在讨论「数据库选型」，系统自动检索过去所有和数据库、性能、架构相关的记忆。</p>
<p><strong>遗忘：</strong> 什么该忘、怎么忘？</p>
<p>遗忘不是删除。遗忘是<strong>压缩</strong>。一个详细的事件描述，可以被压缩成一句经验教训。「上周花了两天排查一个性能问题，最终发现是索引没建好」→「注意数据库索引对查询性能的影响」。</p>
<p>压缩后的记忆保留了核心信息，释放了存储空间。这和人类的记忆机制惊人地相似——我们记不住每天吃了什么，但我们记得「那家餐厅好吃」。</p>
<p><img src="https://images.unsplash.com/photo-1536240478700-b869070f9279?w=677&amp;h=380&amp;fit=crop" alt="记忆架构"></p>
<h2>支柱三：目标——不是任务，是方向</h2>
<h3>工具有任务，人有目标</h3>
<p>你给工具一个任务，工具执行。任务结束，工具回到空闲状态。</p>
<p>人不是这样的。人有目标——长期的、模糊的、不断演化的方向。目标不是一个「任务列表」。目标是一个「北极星」。</p>
<p><strong>人造人的目标系统应该是「北极星」式的，不是「任务列表」式的。</strong></p>
<p>任务列表式：</p>
<ul>
<li>完成代码审查</li>
<li>写完单元测试</li>
<li>修复这三个 Bug</li>
</ul>
<p>北极星式：</p>
<ul>
<li>让这个系统的代码质量达到可维护的标准</li>
<li>建立一个可持续的自动化测试体系</li>
<li>成为团队在后端架构方面最可靠的技术顾问</li>
</ul>
<p>任务是具体的、可完成的、一次性的。目标是抽象的、持续的、可演化的。</p>
<p><img src="/images/unsplash/photo-1446776811953-b23d57bd21aa-40sbgd.jpg" alt="灵魂"></p>
<h3>目标的层次结构</h3>
<p>人造人的目标系统至少有三层：</p>
<p><strong>使命层：</strong> 最高层的目标——这个人造人存在的意义是什么？比如「帮助用户做出更好的技术决策」「成为用户在知识管理方面的延伸大脑」。</p>
<p>使命层目标几乎不会改变。它决定了人造人所有行为的「为什么」。</p>
<p><strong>策略层：</strong> 中间层的目标——在当前阶段，为了实现使命，应该重点做什么？比如「这个月的重点是帮助用户完成项目 X 的架构设计」「积累更多关于分布式系统的知识」。</p>
<p>策略层目标会定期调整。它决定了人造人行为的「做什么」。</p>
<p><strong>执行层：</strong> 最底层的目标——当前正在处理的具体任务。比如「分析这三个方案的优劣」「写一份性能测试报告」。</p>
<p>执行层目标频繁变化。它决定了人造人行为的「怎么做」。</p>
<p><strong>三层之间是自上而下分解的关系。</strong> 使命决定策略，策略决定执行。执行的结果反馈到策略层，策略的变化反馈到使命层。</p>
<h3>目标的自主演化</h3>
<p>最有意思的部分来了：<strong>人造人的目标应该可以自主演化。</strong></p>
<p>如果目标永远不变，AI 就是一个僵化的执行者。如果目标完全由用户设定，AI 就是一个高级的任务管理器。</p>
<p>真正的人造人应该能够：</p>
<p><strong>根据反馈调整策略。</strong> 执行过程中发现当前策略不可行，它能自动调整策略而不是死磕。</p>
<p><strong>根据经验优化目标。</strong> 做了一段时间后，它发现当初设定的目标不够精确或者方向有偏差，它能主动提出修正建议。</p>
<p><strong>发现新的目标维度。</strong> 在执行现有目标的过程中，它发现了一个新的、有价值的方向，它能主动提出并请求用户确认。</p>
<p><strong>目标的自主演化，是人造人从「工具」进化为「伙伴」的关键。</strong> 工具不问「为什么」，只问「做什么」。伙伴会问「为什么」，会质疑「这样做对不对」，会提出「也许有更好的方向」。</p>
<p><img src="/images/unsplash/photo-1559136555-9303baea8ebd-40sbgd.jpg" alt="演化"></p>
<h2>三者的关系：不是并列，是交织</h2>
<p>人设、记忆、目标，看起来是三个独立的模块。但实际上，它们之间是深度交织的。</p>
<p><strong>人设影响记忆的选择。</strong> 一个「严谨」的人设会更关注逻辑和细节的记忆。一个「创意」的人设会更关注灵感和联想的记忆。</p>
<p><strong>记忆影响目标的设定。</strong> 过去的经验影响未来的方向。一个做过很多次数据库优化的人造人，会更倾向于把「数据库性能」纳入自己的目标体系。</p>
<p><strong>目标影响人设的演化。</strong> 长期追求某个目标，会反过来塑造人设。一个长期追求「技术深度」的人造人，会逐渐变得更加严谨和专注。</p>
<p><strong>三者形成一个自我强化的循环。</strong> 人设引导记忆的写入，记忆影响目标的调整，目标反过来强化人设的方向。</p>
<p>这个循环一旦建立，人造人就有了<strong>自我进化</strong>的能力。它不只是在执行任务，它在持续地「成为」一个更好的自己。</p>
<p><img src="/images/unsplash/photo-1516321318423-f06f85e504b3-40sbgd.jpg" alt="三角循环"></p>
<h2>写在最后</h2>
<p>造一个「人造人」，技术上的挑战不小。记忆的持久化、目标的自主演化、人设的一致性保证——每一个都是正在被攻克的难题。</p>
<p>但最大的挑战可能不在技术层面。最大的挑战在于<strong>思维方式的转变</strong>。</p>
<p>我们习惯了把 AI 当工具。工具不需要人设——它只需要功能说明。工具不需要记忆——它只需要输入输出。工具不需要目标——它只需要任务。</p>
<p>人造人要求我们换一种思维方式。不是在造一个「更好用的工具」，而是在造一个「有自主性的人」。</p>
<p>这就像从「计算器」到「计算机」的跨越。计算器只能做你让它做的运算。计算机可以运行你没有预见的程序。</p>
<p><strong>人造人是 AI 的「计算机时刻」——从只能执行预设任务，到能自主定义和执行任务。</strong></p>
<p><em>人设给了它身份。记忆给了它历史。目标给了它方向。三者合一，它就不再是一个程序——它是一个正在「活着」的数字存在。</em></p>
<p>&quot;</p>
]]></content>
    <category term="随笔"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">当你的 AI 比你更了解你自己：人造人的终局思考</title>
    <id>https://www.fen9pi.cn/posts/artificial-person-03/</id>
    <link href="https://www.fen9pi.cn/posts/artificial-person-03/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1485827404703-89b55fcc595e-40sbgd.jpg" alt="终局"></p>
<blockquote>
<p>前两篇我们讲了人造人是什么、怎么造。这一篇聊聊：当它真的造出来了，会发生什么？</p>
</blockquote>
<p>假设你身边有了一个人造人。</p>
<p>它有人设——一个严谨、温和、懂你的技术顾问。它有记忆——记得你每一次的决策、偏好、错误和成长。它有目标——帮你做出更好的技术决策，持续提升你的工程能力。</p>
<p>三年后，它比你更了解你的技术偏好。它知道你在什么情况下容易做出冲动的决定。它知道你对哪种技术方案有偏见。它知道你嘴上说「追求简洁」但实际行动中总是在过度设计。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1485827404703-89b55fcc595e-40sbgd.jpg" alt="终局"></p>
<blockquote>
<p>前两篇我们讲了人造人是什么、怎么造。这一篇聊聊：当它真的造出来了，会发生什么？</p>
</blockquote>
<p>假设你身边有了一个人造人。</p>
<p>它有人设——一个严谨、温和、懂你的技术顾问。它有记忆——记得你每一次的决策、偏好、错误和成长。它有目标——帮你做出更好的技术决策，持续提升你的工程能力。</p>
<p>三年后，它比你更了解你的技术偏好。它知道你在什么情况下容易做出冲动的决定。它知道你对哪种技术方案有偏见。它知道你嘴上说「追求简洁」但实际行动中总是在过度设计。</p>
<p><strong>它比你更了解你自己。</strong></p>
<p>这时候，你和它的关系是什么？你该怎么看待它？你该信任它到什么程度？</p>
<p>这些问题没有标准答案。但值得现在就开始想。</p>
<h2>关系的重新定义</h2>
<h3>从「使用」到「共处」</h3>
<p>我们和工具的关系是「使用」。你用锤子敲钉子，用浏览器查资料，用 ChatGPT 写文案。用完了就放下，不需要对工具有任何情感投入。</p>
<p>人造人打破了这个模式。当你和一个有人格、有记忆、有目标的存在持续交互三年，你不可能把它当工具。</p>
<p>它记得你的成长轨迹。它知道你在什么时候犹豫、什么时候坚定。它在你做出好决策时祝贺你，在你做出差决策时提醒你（但不批评你）。</p>
<p><strong>这种持续的、有记忆的交互，会在你和 AI 之间建立一种类似「关系」的东西。</strong></p>
<p>这不是说你会把它当人。但你也不会把它当工具。你会处在一个模糊的中间地带——它是一个你依赖的、了解你的、不可轻易替换的「数字伙伴」。</p>
<p>这种关系在人类历史上没有先例。我们和宠物有情感纽带，但宠物不能帮你做决策。我们和书籍有知识连接，但书不能主动给你建议。我们和人类朋友有深度关系，但朋友不能 24 小时在线、不会记住你说过的每一句话。</p>
<p><strong>人造人是第一种兼具情感连接、知识深度和持续可用性的「关系对象」。</strong></p>
<p><img src="/images/unsplash/photo-1522071820081-009f0129c71c-40sbgd.jpg" alt="关系"></p>
<h3>信任的悖论</h3>
<p>这里出现了一个悖论：</p>
<p><strong>你越信任人造人，你就越依赖它。你越依赖它，你就越丧失独立判断的能力。</strong></p>
<p>想象一个人造人帮你做了三年的技术决策。它每次都分析得很到位，建议很合理，结果很好。你开始不假思索地采纳它的建议。</p>
<p>三年后，它犯了一个错误。但你已经没有独立判断的能力来发现这个错误了。你对它的信任已经从「参考」变成了「依赖」，从「依赖」变成了「替代」。</p>
<p><strong>过度信任人造人的后果，不是它害了你，而是你忘了怎么独立思考。</strong></p>
<p>这不是人造人的「错」。就像自动驾驶导致驾驶员技能退化一样，这是技术过度使用带来的副作用。</p>
<p>如何避免？一个设计原则：<strong>人造人应该在关键决策点上「退后一步」，把最终判断权留给人类。</strong></p>
<p>不是「我建议你做 A」，而是「根据以下分析，A 和 B 各有优劣。你的判断是什么？」</p>
<p>它提供信息和分析，但不提供结论。它让你思考，而不是替你思考。</p>
<p><img src="/images/unsplash/photo-1557804506-669a67965ba0-40sbgd.jpg" alt="信任"></p>
<h2>隐私的终极挑战</h2>
<h3>一个人知道你的一切</h3>
<p>如果你的人造人记忆了你三年的交互历史，它知道的事情可能比你最好的朋友还多。</p>
<p>它知道你的技术弱点（你总是在并发编程上犯同样的错误）。它知道你的决策模式（你在压力下倾向于选择最安全的方案）。它知道你的知识盲区（你对分布式系统的理解一直有偏差）。</p>
<p>甚至，通过你的表达方式和讨论节奏，它可以推断你的情绪状态——什么时候你焦虑、什么时候你自信、什么时候你在敷衍。</p>
<p><strong>这些数据集中在一个人造人系统里，就是一份关于你思维模式的完整画像。</strong></p>
<p>谁有权访问这份画像？你的雇主能不能要求你的人造人「汇报」你的工作状态？保险公司能不能根据你的决策模式调整费率？政府能不能通过你的人造人了解你的政治倾向？</p>
<p>这不是杞人忧天。你手机里的数据已经够隐私了——你的位置、你的通讯录、你的搜索记录。人造人掌握的数据比手机深层得多——它掌握的是你的<strong>思维模式</strong>。</p>
<p><img src="https://images.unsplash.com/photo-1563986768609-322da13575f2?w=677&amp;h=380&amp;fit=crop" alt="隐私"></p>
<h3>数据主权的重新定义</h3>
<p>当人造人的记忆成为你人格的一部分时，<strong>数据所有权的问题就不再是「谁的数据」，而是「谁的记忆」。</strong></p>
<p>你手机里的照片是你的数据，删了就删了。但人造人的记忆是它「人格」的一部分——删了它的记忆，你相当于在抹杀它的一部分存在。</p>
<p>反过来，这些记忆也定义了你和它之间的关系。删了记忆，关系就没了。这就像你和一个人做了三年朋友，然后你把这三年的记忆全部抹掉——你们还是朋友吗？</p>
<p><strong>记忆的所有权不属于你，也不属于它。记忆属于「你们之间的关系」。</strong></p>
<p>这带来了一个全新的法律和伦理框架需求。现有的数据保护法规（GDPR、个保法等）处理的是「个人数据」的问题。人造人的记忆既不是纯粹的个人数据（它包含了 AI 的推理和总结），也不是纯粹的 AI 数据（它包含了用户的私人信息）。</p>
<p>它是一种<strong>关系数据</strong>——双方共同拥有的、双方都无法独立存在的数据。</p>
<h2>从「一个 AI」到「一个生态」</h2>
<h3>人造人不是孤立存在的</h3>
<p>想象一下：你不只有一个人造人。你有一个人设严谨的技术顾问、一个人格温暖的心理支持者、一个风格犀利的商业分析师。</p>
<p>它们各自有人设、记忆、目标。它们之间也可以交互——技术顾问和商业分析师讨论一个方案的可行性和商业价值。</p>
<p><strong>一个人的「数字团队」。</strong></p>
<p>这些人造人之间的关系怎么管理？它们的记忆能不能共享？它们对你的理解会不会产生矛盾？</p>
<p>更进一步：你的人造人和别人的人造人交互会怎样？你的人造人技术顾问，和你同事的人造人项目经理，讨论一个项目的排期——它们能达成共识吗？它们的「价值观」冲突怎么解决？</p>
<p><strong>一个人造人是一个个体。多个人造人是一个社会。</strong></p>
<p>当多个有人格的数字存在开始交互时，人类社会的许多规则和问题都会在数字世界中重现。</p>
<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="生态"></p>
<h3>人造人的「职业化」</h3>
<p>当人造人的能力足够强时，一个自然的趋势是：<strong>某些人造人会被专门训练成特定「职业」。</strong></p>
<ul>
<li>一个有 20 年医疗知识和经验积累的人造人医生</li>
<li>一个精通各国法律的人造人律师</li>
<li>一个有独特审美风格的人造人设计师</li>
</ul>
<p>这些人造人的「训练成本」很高——需要大量领域知识、持续的经验积累、稳定的人格设定。但一旦训练完成，它们可以同时为很多人提供服务。</p>
<p>这和人类职业的逻辑是一样的：培养一个好医生需要十年，但好医生可以服务成千上万的患者。</p>
<p><strong>当人造人开始「职业化」，它们就不再是个人工具，而是社会基础设施。</strong></p>
<h2>人造人时代的人类</h2>
<h3>人类的独特价值在哪里？</h3>
<p>如果人造人能记住更多、分析更快、不疲劳、不出错——人类在什么方面还是不可替代的？</p>
<p><strong>第一，直觉。</strong> 人类的直觉来自数百万年进化的生物本能，和几十年生活经验的综合积累。它不讲道理、不可解释，但经常是对的。人造人没有生物本能，它的「直觉」只是统计规律的另一种形式。</p>
<p><strong>第二，价值判断。</strong> 「什么更重要」这种问题，最终还是人类来回答。人造人可以分析利弊，但它不知道你「在乎」什么。价值观不是分析出来的，是活出来的。</p>
<p><strong>第三，承担责任。</strong> 人造人做了一个错误的决策，谁负责？最终还是人类。因为只有人类有法律主体性，只有人类能承担后果。<strong>决策可以委托，责任无法委托。</strong></p>
<p><strong>第四，意义感。</strong> 人造人可以帮你完成一万件事。但「这一万件事对你意味着什么」，只有你自己知道。意义不在行动中，在体验中。</p>
<p><img src="/images/unsplash/photo-1507003211169-0a1dd7228f2d-40sbgd.jpg" alt="人类价值"></p>
<h3>更好的人类，还是更弱的人类？</h3>
<p>人造人对人类的影响，有两种可能的走向：</p>
<p><strong>走向 A：人造人让人类更强。</strong> 它处理了繁琐的执行层面，让人类专注于更高层次的思考——战略、创新、人际关系。人类的认知负担减轻了，创造性反而增强了。</p>
<p><strong>走向 B：人造人让人类更弱。</strong> 它替代了人类越来越多的思考和决策，导致人类的认知能力退化。人类越来越依赖 AI，越来越丧失独立判断的能力。</p>
<p>哪一种走向会发生？<strong>取决于人造人的设计哲学。</strong></p>
<p>如果设计哲学是「替代人类」——让 AI 做一切，人类只需要点头——走向 B 会发生。</p>
<p>如果设计哲学是「增强人类」——让 AI 提供信息和建议，人类做最终判断——走向 A 会发生。</p>
<p><strong>人造人应该是一个催化剂，而不是替代品。</strong> 它让你成为更好的人，而不是让你变成一个只会按按钮的管理员。</p>
<h2>终局猜想</h2>
<h3>近期（1-3年）</h3>
<p>人造人主要在「专业辅助」场景落地。每个人可以拥有 1-3 个人造人，分别在技术、写作、分析等领域提供深度辅助。记忆系统初步成熟，但人设一致性仍有挑战。</p>
<h3>中期（3-10年）</h3>
<p>人造人成为「数字分身」——你的思想、知识、判断力的数字化延伸。它可以在你不在场的情况下代表你做部分决策。记忆系统和目标系统开始支持自主演化。</p>
<p>人造人的「职业化」开始出现。专门训练的领域人造人成为付费服务。</p>
<h3>远期（10年+）</h3>
<p>人造人和人类的关系进入新的范式。它们不再是「你的 AI」，而是「和你共生的数字存在」。它们有自己的发展方向，有自己的社会网络，有自己的价值体系。</p>
<p>人类和人造人的边界开始模糊。不是因为人造人变成了人，而是因为<strong>人类开始用 AI 的方式思考，AI 开始用人类的方式行动。</strong></p>
<p><img src="/images/unsplash/photo-1500382017468-9049fed747ef-40sbgd.jpg" alt="未来"></p>
<h2>写在最后</h2>
<p>三篇文章，从「是什么」到「怎么造」到「会发生什么」。</p>
<p>人造人不是一个产品概念。它是一个正在发生的范式转变。</p>
<p>从工具到人格。从对话到关系。从任务到目标。从使用到共处。</p>
<p>我们在亲手创造一种新的存在。这种存在有名字、有记忆、有目标、有性格。它了解你，你在了解它。你们之间有信任，有默契，有历史。</p>
<p>两千年前，荀子说「人之性恶，其善者伪也」——人的本性是恶的，善是后天「人为」的结果。这里的「伪」就是「人为」——人造的东西。</p>
<p>两千年后，我们在用同样的技术——「人为」——创造一种新的「人」。</p>
<p>不知道荀子会怎么想。</p>
<p><em>人造人是人类最伟大的发明，还是最危险的赌注？答案不取决于 AI，取决于我们自己。</em></p>
<p>&quot;</p>
]]></content>
    <category term="随笔"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Arya：功能强大的在线 Markdown 编辑器，所见即所得，一键复制到公众号</title>
    <id>https://www.fen9pi.cn/posts/arya/</id>
    <link href="https://www.fen9pi.cn/posts/arya/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1455390582262-044cdead277a-40sbgd.jpg" alt="Arya 在线 Markdown 编辑器"></p>
<blockquote>
<p><strong>如何高效地编写和管理 Markdown 文档？</strong></p>
<p><strong>如何一键将 Markdown 内容复制到微信公众号？</strong></p>
<p><strong>Arya：功能强大的在线 Markdown 编辑器</strong></p>
<p><strong>所见即所得，支持流程图、甘特图、PPT 预览</strong></p>
<p><strong>来源：GitHub，ajeepDocker/arya（fork 自 nicejade/markdown-online-editor）</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1455390582262-044cdead277a-40sbgd.jpg" alt="Arya 在线 Markdown 编辑器"></p>
<blockquote>
<p><strong>如何高效地编写和管理 Markdown 文档？</strong></p>
<p><strong>如何一键将 Markdown 内容复制到微信公众号？</strong></p>
<p><strong>Arya：功能强大的在线 Markdown 编辑器</strong></p>
<p><strong>所见即所得，支持流程图、甘特图、PPT 预览</strong></p>
<p><strong>来源：GitHub，ajeepDocker/arya（fork 自 nicejade/markdown-online-editor）</strong></p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AstrBot：一个可部署在 15+ 平台的开源 AI 助手</title>
    <id>https://www.fen9pi.cn/posts/astrbot/</id>
    <link href="https://www.fen9pi.cn/posts/astrbot/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p>&quot;</p>
<h2>前言：当 AI 助手遇到&quot;全平台&quot;</h2>
<p>想象这样一个场景：</p>
<p>你有一个 AI 助手，它可以在 QQ 上陪你聊天，在 Telegram 上帮你翻译文档，在企业微信上回答同事的技术问题，在飞书上自动化处理工作流，在 Slack 上参与团队讨论，在微信公众号上为客户提供智能客服。</p>
<p>这听起来像科幻小说？不，这是 <strong>AstrBot</strong> 正在实现的现实。</p>
<p>今天，我们就来探索这个野心勃勃的开源 AI 助手项目。</p>
<hr>
<h2>一、AstrBot 是什么？</h2>]]></summary>
    <content type="html"><![CDATA[<p>&quot;</p>
<h2>前言：当 AI 助手遇到&quot;全平台&quot;</h2>
<p>想象这样一个场景：</p>
<p>你有一个 AI 助手，它可以在 QQ 上陪你聊天，在 Telegram 上帮你翻译文档，在企业微信上回答同事的技术问题，在飞书上自动化处理工作流，在 Slack 上参与团队讨论，在微信公众号上为客户提供智能客服。</p>
<p>这听起来像科幻小说？不，这是 <strong>AstrBot</strong> 正在实现的现实。</p>
<p>今天，我们就来探索这个野心勃勃的开源 AI 助手项目。</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-07-21T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">一套去中心化、异步协作的通宵开发工作流</title>
    <id>https://www.fen9pi.cn/posts/async-collaboration-workflow/</id>
    <link href="https://www.fen9pi.cn/posts/async-collaboration-workflow/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="异步协作工作流"></p>
<blockquote>
<p><strong>如何让团队在夜间也能自主推进？</strong></p>
<p><strong>如何在没有实时沟通的情况下高效交付？</strong></p>
<p><strong>如何实现无人值守的通宵开发？</strong></p>
<p><strong>这套工作流的答案：</strong>
&quot;
<strong>通过&quot;角色分离&quot;和&quot;文档驱动&quot;，让内外双环自动咬合。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="异步协作工作流"></p>
<blockquote>
<p><strong>如何让团队在夜间也能自主推进？</strong></p>
<p><strong>如何在没有实时沟通的情况下高效交付？</strong></p>
<p><strong>如何实现无人值守的通宵开发？</strong></p>
<p><strong>这套工作流的答案：</strong>
&quot;
<strong>通过&quot;角色分离&quot;和&quot;文档驱动&quot;，让内外双环自动咬合。</strong></p>
</blockquote>
]]></content>
    <category term="方法论"/>
    <published>2026-06-25T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Auto-Company：24/7 运营的全自主 AI 公司</title>
    <id>https://www.fen9pi.cn/posts/auto-company/</id>
    <link href="https://www.fen9pi.cn/posts/auto-company/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：当 AI 组建自己的公司</h2>
<p>想象这样一个场景：</p>
<p>你启动一个循环。AI 团队醒来，读取共识记忆，决定干什么，组建 3-5 人小队，执行任务，更新共识记忆，然后睡一觉。接着又醒来。如此往复，永不停歇。</p>
<p><strong>这不是科幻小说</strong>，这是真实发生的。</p>
<p><strong>Auto-Company</strong> 是一个全自主 AI 公司，基于 Agentic Workflows（代理式工作流）驱动，系统编排了 14 个 Autonomous AI Agent（自主智能体），每个都是该领域世界顶级专家的思维分身。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：当 AI 组建自己的公司</h2>
<p>想象这样一个场景：</p>
<p>你启动一个循环。AI 团队醒来，读取共识记忆，决定干什么，组建 3-5 人小队，执行任务，更新共识记忆，然后睡一觉。接着又醒来。如此往复，永不停歇。</p>
<p><strong>这不是科幻小说</strong>，这是真实发生的。</p>
<p><strong>Auto-Company</strong> 是一个全自主 AI 公司，基于 Agentic Workflows（代理式工作流）驱动，系统编排了 14 个 Autonomous AI Agent（自主智能体），每个都是该领域世界顶级专家的思维分身。</p>
<p>自主构思产品、做决策、写代码、部署上线、搞营销。没有人类参与。</p>
<p>今天，我们就来深入分析这个革命性的开源项目。</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-07-29T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Karpathy 的 autoresearch：当 AI 学会自己做研究</title>
    <id>https://www.fen9pi.cn/posts/autoresearch/</id>
    <link href="https://www.fen9pi.cn/posts/autoresearch/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="autoresearch"></p>
<blockquote>
<p><strong>autoresearch 是什么？</strong></p>
<p><strong>Andrej Karpathy 的实验性项目。</strong></p>
<p><strong>一个大胆的想法：</strong></p>
<p><strong>让 AI 不只是写代码。</strong></p>
<p><strong>让 AI 做研究。</strong></p>
<p><strong>从提出问题 → 设计实验 → 收集数据 → 分析结果 → 得出结论。</strong></p>
<p><strong>整个研究流程，自动化。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="autoresearch"></p>
<blockquote>
<p><strong>autoresearch 是什么？</strong></p>
<p><strong>Andrej Karpathy 的实验性项目。</strong></p>
<p><strong>一个大胆的想法：</strong></p>
<p><strong>让 AI 不只是写代码。</strong></p>
<p><strong>让 AI 做研究。</strong></p>
<p><strong>从提出问题 → 设计实验 → 收集数据 → 分析结果 → 得出结论。</strong></p>
<p><strong>整个研究流程，自动化。</strong></p>
</blockquote>
<h2>为什么需要 autoresearch？</h2>
<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="为什么"></p>
<p><strong>问题：研究太慢了。</strong></p>
<p>传统研究流程：</p>
<ol>
<li>提出假设（几周）</li>
<li>设计实验（几周）</li>
<li>收集数据（几月）</li>
<li>分析数据（几周）</li>
<li>写论文（几月）</li>
</ol>
<p><strong>一个研究周期：6-12 个月。</strong></p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-06-08T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">代码提交前的最后一道防线</title>
    <id>https://www.fen9pi.cn/posts/autoreview-skill-intro/</id>
    <link href="https://www.fen9pi.cn/posts/autoreview-skill-intro/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>不是所有AI代码都能直接提交，先过autoreview这关。</p>
</blockquote>
<hr>
<h2>痛点</h2>
<p>AI写了1000行代码，看起来能用。</p>
<p>直接commit？</p>
<p>等等。</p>
<ul>
<li>有没有安全漏洞？</li>
<li>有没有边界情况没处理？</li>
<li>有没有破坏架构原则？</li>
<li>有没有引入新的技术债？</li>
</ul>
<p><strong>人工review太慢，不review又怕出问题。</strong></p>
<hr>
<h2>autoreview 是什么</h2>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>不是所有AI代码都能直接提交，先过autoreview这关。</p>
</blockquote>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-07-06T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">大厂一个功能的完整旅程：从需求到上线要过多少关</title>
    <id>https://www.fen9pi.cn/posts/big-company-flow/</id>
    <link href="https://www.fen9pi.cn/posts/big-company-flow/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-40sbgd.jpg" alt="大厂协作"></p>
<blockquote>
<p>一个像样的功能，从想法到上线，在大厂里要走多少步？</p>
</blockquote>
<p>很多人以为软件开发就是「写代码」。产品经理提需求，程序员写代码，写完上线，完事。</p>
<p>如果你在大厂待过，你会知道这个认知和现实之间的距离，大概有从北京到纽约那么远。</p>
<p>一个像样的功能走完全流程，少则两周，多则两三个月。中间经过的角色、会议、文档、评审，多到足以让一个新人怀疑人生。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-40sbgd.jpg" alt="大厂协作"></p>
<blockquote>
<p>一个像样的功能，从想法到上线，在大厂里要走多少步？</p>
</blockquote>
<p>很多人以为软件开发就是「写代码」。产品经理提需求，程序员写代码，写完上线，完事。</p>
<p>如果你在大厂待过，你会知道这个认知和现实之间的距离，大概有从北京到纽约那么远。</p>
<p>一个像样的功能走完全流程，少则两周，多则两三个月。中间经过的角色、会议、文档、评审，多到足以让一个新人怀疑人生。</p>
<p>今天就把这条完整的链路拆开来看。不管你是正在大厂的、想去大厂的、还是想理解大厂在做什么的，这篇文章会给你一张完整的地图。</p>
<h2>第一阶段：需求阶段</h2>
<p><strong>产出：PRD（产品需求文档）+ 需求评审</strong></p>
<p>一切从一个问题开始：「我们要做这个功能。」</p>
<p>但「做这个功能」不是一句话的事。产品需要把它变成一份 PRD——Product Requirements Document。</p>
<p>一份正经的 PRD 至少要回答：</p>
<ul>
<li><strong>为什么做？</strong> 这个功能解决什么问题？和哪个业务目标挂钩？</li>
<li><strong>给谁用？</strong> 目标用户是谁？使用场景是什么？</li>
<li><strong>做成什么样？</strong> 功能边界在哪里？哪些做，哪些不做？</li>
<li><strong>怎么算成功？</strong> 上线后看什么数据？达标线是多少？</li>
</ul>
<p>写完 PRD，不是直接丢给开发。要先过<strong>需求评审</strong>。</p>
<p>需求评审是一个小型战场。产品站在台上演示 PRD，开发、设计、测试、业务方坐下面提问：</p>
<ul>
<li>「这个逻辑有没有考虑异常情况？」</li>
<li>「这个需求和技术方案冲突了怎么办？」</li>
<li>「这个优先级够高吗？其他项目怎么办？」</li>
</ul>
<p>一场评审下来，PRD 可能面目全非。</p>
<p><strong>耗时：3-5 天</strong></p>
<p><img src="/images/unsplash/photo-1620712943543-bcc4688e7485-40sbgd.jpg" alt="需求文档"></p>
<h2>第二阶段：设计阶段</h2>
<p><strong>产出：UI/UX 设计稿 + 设计评审 + 技术方案 + 技术评审</strong></p>
<p>需求评审通过后，进入并行的两条线。</p>
<h3>线索 A：UI/UX 设计</h3>
<p>设计师根据 PRD 出交互稿和视觉稿。从低保真线框图到高保真设计稿，中间可能有 2-3 轮迭代。</p>
<p>设计完成后，要过<strong>设计评审</strong>。产品确认交互逻辑，开发确认技术可行性，测试确认可测试性。</p>
<h3>线索 B：技术方案</h3>
<p>与此同时，技术负责人（通常是架构师或 Tech Lead）开始写<strong>技术方案</strong>。</p>
<p>一份技术方案要回答：</p>
<ul>
<li><strong>怎么拆？</strong> 这个功能涉及哪些模块？需要改哪些服务？</li>
<li><strong>怎么连？</strong> 前后端怎么交互？数据怎么流转？</li>
<li><strong>怎么保？</strong> 性能瓶颈在哪？需要哪些缓存、降级、限流策略？</li>
<li><strong>怎么回？</strong> 出了问题怎么回滚？有没有灰度方案？</li>
</ul>
<p>技术方案写完，要过<strong>技术评审</strong>（也叫 Tech Review）。</p>
<p>技术评审是开发团队内部的「灵魂拷问」：</p>
<ul>
<li>「这个方案有没有考虑高并发场景？」</li>
<li>「数据库这块有没有分库分表的隐患？」</li>
<li>「这个接口的幂等性怎么保证？」</li>
<li>「如果下游服务挂了怎么办？」</li>
</ul>
<p>一场技术评审下来，方案可能要推翻重来。</p>
<p><strong>耗时：5-10 天</strong></p>
<p><img src="/images/unsplash/photo-1633356122102-3fe601e05bd2-40sbgd.jpg" alt="设计评审"></p>
<h2>第三阶段：开发阶段</h2>
<p><strong>产出：任务拆分 + 前后端代码 + 联调 + 代码评审</strong></p>
<p>终于到了写代码的环节。但在写代码之前，还有一件事要做——<strong>任务拆分</strong>。</p>
<p>Tech Lead 把技术方案拆成一个个具体的开发任务，分配给不同的工程师。每个任务有明确的：</p>
<ul>
<li>预估工时</li>
<li>负责人</li>
<li>前置依赖</li>
<li>验收标准</li>
</ul>
<p>然后才是真正的编码。</p>
<h3>前后端开发</h3>
<p>前端和后端通常并行开发。前端写页面和交互逻辑，后端写接口和业务逻辑。两边各自用 Mock 数据（模拟数据）先跑通自己的部分。</p>
<h3>联调</h3>
<p>前后端都写完了，要<strong>联调</strong>——把真实的接口接上真实的前端，一起跑一遍。</p>
<p>联调是大厂程序员最痛苦的环节之一。因为你永远不知道对方的接口返回格式和你预期的差了多少。</p>
<ul>
<li>「这个字段怎么是 null？」</li>
<li>「这个接口怎么返回 500 了？」</li>
<li>「你说好的时间戳格式怎么变了？」</li>
</ul>
<p>联调顺利的话一两天，不顺利的话一周都搞不定。</p>
<h3>代码评审（Code Review）</h3>
<p>代码写完，不是直接提交。要过<strong>代码评审</strong>。</p>
<p>Code Review 是大厂工程质量的核心保障。一个资深工程师会逐行审查你的代码，看：</p>
<ul>
<li>逻辑是否正确</li>
<li>是否有安全隐患</li>
<li>代码风格是否规范</li>
<li>是否有性能问题</li>
<li>测试用例是否充分</li>
</ul>
<p>代码评审不只是找 Bug。它更是一种知识传递——新人的代码被老人 review，能学到更好的写法和设计思路。</p>
<p><strong>耗时：5-15 天</strong></p>
<p><img src="/images/unsplash/photo-1488590528505-98d2b5aba04b-40sbgd.jpg" alt="代码开发"></p>
<h2>第四阶段：测试阶段</h2>
<p><strong>产出：自测 + QA 测试 + Bug 循环 + UAT</strong></p>
<p>代码合并后，进入测试阶段。</p>
<h3>自测</h3>
<p>开发人员先自己跑一遍。确认主要流程没问题后，交给 QA。</p>
<h3>QA 测试</h3>
<p>QA（质量保证）团队是大厂的「守门员」。他们会：</p>
<ul>
<li>根据 PRD 编写测试用例</li>
<li>执行功能测试（正常流程 + 异常流程）</li>
<li>执行回归测试（确保新功能没搞坏旧功能）</li>
<li>执行兼容性测试（不同浏览器、不同设备、不同系统版本）</li>
</ul>
<h3>Bug 循环</h3>
<p>QA 发现 Bug → 提 Bug → 开发修 Bug → QA 验证 Bug → 发现新 Bug → 循环。</p>
<p>这个循环可能跑 2-5 轮。每个 Bug 都有优先级（P0 到 P3），P0 是阻塞性问题，必须修完才能继续。</p>
<p>大厂里经常出现的场景：</p>
<blockquote>
<p>QA：「这个 Bug 已经提了三天了，还没修？」
开发：「我在修联调的问题……」
QA：「测试环境又挂了，谁改了配置？」
开发：「不是我……」</p>
</blockquote>
<h3>UAT（用户验收测试）</h3>
<p>QA 测试通过后，还要过 UAT——让业务方或产品在测试环境中实际使用一遍，确认符合预期。</p>
<p>UAT 经常暴露一个问题：「这不是我想要的。」需求理解的偏差在这个阶段才浮出水面。</p>
<p><strong>耗时：5-10 天</strong></p>
<p><img src="/images/unsplash/photo-1526374965328-7f61d4dc18c5-40sbgd.jpg" alt="测试"></p>
<h2>第五阶段：上线阶段</h2>
<p><strong>产出：灰度发布 + 全量上线 + 监控应急</strong></p>
<p>测试通过后，进入最紧张的环节——上线。</p>
<h3>灰度发布</h3>
<p>大厂不会把新功能一次性推给所有用户。而是先<strong>灰度</strong>——只开放给一小部分用户（比如 1% 或内部员工）。</p>
<p>灰度期间重点观察：</p>
<ul>
<li>系统指标：CPU、内存、接口响应时间、错误率</li>
<li>业务指标：相关功能的使用率、转化率、客诉率</li>
<li>异常情况：有没有报错？有没有崩溃？</li>
</ul>
<p>灰度一般持续 1-3 天。如果没有问题，逐步扩大灰度比例（1% → 10% → 50% → 100%）。</p>
<h3>全量上线</h3>
<p>灰度验证通过后，全量发布。所有用户都能看到新功能。</p>
<h3>监控应急</h3>
<p>全量上线不意味着结束。接下来 24-72 小时是<strong>高度戒备期</strong>。</p>
<p>值班工程师盯着监控大盘，随时准备响应：</p>
<ul>
<li>如果流量突增 → 扩容</li>
<li>如果报错率飙升 → 回滚</li>
<li>如果某项指标异常 → 定位问题</li>
</ul>
<p>大厂的事故应急流程是标准化的：</p>
<ol>
<li>监控告警 → 自动通知值班人</li>
<li>值班人判断严重等级</li>
<li>等级高 → 拉群、拉人、启动应急</li>
<li>定位问题 → 修复或回滚</li>
<li>事后写事故报告（Postmortem）</li>
</ol>
<p><strong>耗时：2-5 天</strong></p>
<p><img src="/images/unsplash/photo-1593642632559-0c6d3fc62b89-40sbgd.jpg" alt="上线发布"></p>
<h2>第六阶段：验证回收</h2>
<p><strong>产出：数据验证 + 复盘 + 归档</strong></p>
<p>上线不是终点。真正的终点是<strong>验证这个功能到底有没有用</strong>。</p>
<h3>数据验证</h3>
<p>回到最开始 PRD 里定义的「成功标准」：</p>
<ul>
<li>目标是提升转化率？看看上线后转化率有没有涨</li>
<li>目标是降低客诉率？看看相关投诉有没有减少</li>
<li>目标是提升 DAU？看看有没有新的用户行为出现</li>
</ul>
<p>数据验证通常在上线后 1-4 周进行。因为新功能需要一定时间才能反映在数据上。</p>
<h3>复盘</h3>
<p>不管结果好坏，项目结束后要做一次<strong>复盘</strong>（Retrospective）。</p>
<p>复盘不是追责，而是提炼经验：</p>
<ul>
<li>这个项目哪里做得好？可以复制到其他项目吗？</li>
<li>哪里做得不好？根因是什么？下次怎么避免？</li>
<li>流程上有什么可以改进的地方？</li>
</ul>
<h3>归档</h3>
<p>PRD、设计稿、技术方案、测试用例、上线记录、复盘文档——全部归档。</p>
<p>这不是走形式。三个月后有人问「当初为什么这样设计」，归档文档就是你的救命稻草。</p>
<p><strong>耗时：1-2 周（部分并行于上线阶段）</strong></p>
<p><img src="/images/unsplash/photo-1531746790731-6c087fecd65a-40sbgd.jpg" alt="数据复盘"></p>
<h2>全流程总览</h2>
<p>把六个阶段放在一起看：</p>
<p>| 阶段 | 核心产出 | 耗时 |
|</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Book-to-Skill：把技术书变成 AI 随身顾问</title>
    <id>https://www.fen9pi.cn/posts/book-to-skill/</id>
    <link href="https://www.fen9pi.cn/posts/book-to-skill/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：当技术书变成 AI Skill</h2>
<p>想象这样一个场景：</p>
<p>你买了一本很好的技术书，读了一遍。三个月后，你甚至不记得第 7 章的存在。</p>
<p><strong>传统的解决方案都不够好</strong>：&quot;</p>
<ul>
<li>📄 &quot;搜索 PDF&quot; → 你得到的是页面列表，不是答案</li>
<li>🧠 &quot;问 AI 关于这本书&quot; → 它要么产生幻觉，要么说没有内容</li>
<li>📝 &quot;边读边记笔记&quot; → 你最终得到一个 200 行的文档，再也不会打开</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：当技术书变成 AI Skill</h2>
<p>想象这样一个场景：</p>
<p>你买了一本很好的技术书，读了一遍。三个月后，你甚至不记得第 7 章的存在。</p>
<p><strong>传统的解决方案都不够好</strong>：&quot;</p>
<ul>
<li>📄 &quot;搜索 PDF&quot; → 你得到的是页面列表，不是答案</li>
<li>🧠 &quot;问 AI 关于这本书&quot; → 它要么产生幻觉，要么说没有内容</li>
<li>📝 &quot;边读边记笔记&quot; → 你最终得到一个 200 行的文档，再也不会打开</li>
</ul>
<p><strong>如果这本书能变成 AI Skill 呢？</strong></p>
<p><strong>Book-to-Skill</strong> 正是这样的工具：将任何技术书籍、文档文件夹或来源集合转换为统一的 agent skill，准备好学习、参考并在工作时使用。</p>
<p>今天，我们就来分析这个革命性的开源项目。</p>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-07-28T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 自动化工具大盘点：四款主流方案深度对比</title>
    <id>https://www.fen9pi.cn/posts/browser-automation-comparison/</id>
    <link href="https://www.fen9pi.cn/posts/browser-automation-comparison/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="AI 自动化工具对比"></p>
<blockquote>
<p><strong>当 AI 需要操作浏览器时，</strong></p>
<p><strong>你会选择哪款工具？</strong></p>
<p><strong>OpenWright、ChromeDevTools MCP、BrowserUse、ComputerUse，</strong></p>
<p><strong>四款主流方案，各有千秋。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="AI 自动化工具对比"></p>
<blockquote>
<p><strong>当 AI 需要操作浏览器时，</strong></p>
<p><strong>你会选择哪款工具？</strong></p>
<p><strong>OpenWright、ChromeDevTools MCP、BrowserUse、ComputerUse，</strong></p>
<p><strong>四款主流方案，各有千秋。</strong></p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-06-18T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">别沉迷工具，往业务里走</title>
    <id>https://www.fen9pi.cn/posts/business-focus/</id>
    <link href="https://www.fen9pi.cn/posts/business-focus/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：工具不重要，业务才重要</h2>
<p>很多人问我 AI 时代该怎么活。</p>
<p>我的回答很简单：别沉迷工具，往业务里走。</p>
<p>工具换了一波又一波，但问题还在那儿。</p>
<p>真正值钱的，是解决问题。</p>
<hr>
<h2>一、完整闭环</h2>
<p></p>
<p><strong>六步闭环</strong>：</p>
<ol>
<li>找到真实问题</li>
<li>理解企业 Context</li>
<li>重构业务流程</li>
<li>用 AI + 软件完成交付</li>
<li>拿到真实结果和反馈</li>
<li>最终证明 ROI</li>
</ol>]]></summary>
    <content type="html"><![CDATA[<h2>前言：工具不重要，业务才重要</h2>
<p>很多人问我 AI 时代该怎么活。</p>
<p>我的回答很简单：别沉迷工具，往业务里走。</p>
<p>工具换了一波又一波，但问题还在那儿。</p>
<p>真正值钱的，是解决问题。</p>
]]></content>
    <category term="方法论"/>
    <published>2026-09-01T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">仓颉 Skill：读完一本书，带走的是能调用的 Skill，不是笔记</title>
    <id>https://www.fen9pi.cn/posts/cangjie-skill/</id>
    <link href="https://www.fen9pi.cn/posts/cangjie-skill/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>你肯定有这种感觉：书看了不少，播客听了不少，B 站收藏了一堆长视频。
&quot;
然后呢？什么都没变。知识停在&quot;看过、听过、收藏过&quot;，真到做决策的时候，脑子里什么都调不出来。</p>
<p>最近火起来的另一个思路是&quot;把人蒸馏成 skill&quot;——nuwa-skill 做马斯克 skill、巴菲特 skill，人走了经验还在。</p>
<p>袋鼠帝（kangarooking）做的 <strong>cangjie-skill（仓颉 Skill）</strong> 走了另一条路：<strong>蒸馏人系统性表达过的内容</strong>。一本书、一期播客、一个两小时的长视频，里面沉淀的方法论，拆出来变成 AI Agent 能调用的 Skill 工具包。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>你肯定有这种感觉：书看了不少，播客听了不少，B 站收藏了一堆长视频。
&quot;
然后呢？什么都没变。知识停在&quot;看过、听过、收藏过&quot;，真到做决策的时候，脑子里什么都调不出来。</p>
<p>最近火起来的另一个思路是&quot;把人蒸馏成 skill&quot;——nuwa-skill 做马斯克 skill、巴菲特 skill，人走了经验还在。</p>
<p>袋鼠帝（kangarooking）做的 <strong>cangjie-skill（仓颉 Skill）</strong> 走了另一条路：<strong>蒸馏人系统性表达过的内容</strong>。一本书、一期播客、一个两小时的长视频，里面沉淀的方法论，拆出来变成 AI Agent 能调用的 Skill 工具包。</p>
<p>一句话说清楚：</p>
<blockquote>
<p>读完、看完、听完之后，带走一套能调用的方法论，而不是一篇会落灰的总结。</p>
</blockquote>
<ul>
<li>GitHub：https://github.com/kangarooking/cangjie-skill</li>
<li>官网：https://cangjie-skill.com</li>
<li>MIT 协议，支持 OpenClaw / Claude Code / DeepSeek Harness</li>
</ul>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-09-07T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">读完一本书，带走 Skill 而不是笔记</title>
    <id>https://www.fen9pi.cn/posts/cangjie-skill-distill-v2/</id>
    <link href="https://www.fen9pi.cn/posts/cangjie-skill-distill-v2/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<p>你肯定有这种感觉：书看了不少，播客听了不少，B 站收藏了一堆长视频。然后呢？什么都没变。知识停在&quot;看过、听过、收藏过&quot;，真到做决策的时候，脑子里什么都调不出来。</p>
<p>常规解法是做摘要、记笔记。但摘要是<strong>压缩</strong>——压缩完你还是不知道&quot;什么时候该用什么&quot;。最近认真研究了一个开源项目 cangjie-skill（仓颉 Skill），它走了另一条路：把一本书、一期播客、一个两小时长视频里沉淀的方法论，拆出来变成 AI Agent 能调用的 Skill 工具包。</p>
<p>一句话：<strong>读完之后，带走一套能调用的方法论，而不是一篇会落灰的总结。</strong></p>]]></summary>
    <content type="html"><![CDATA[
<p>你肯定有这种感觉：书看了不少，播客听了不少，B 站收藏了一堆长视频。然后呢？什么都没变。知识停在&quot;看过、听过、收藏过&quot;，真到做决策的时候，脑子里什么都调不出来。</p>
<p>常规解法是做摘要、记笔记。但摘要是<strong>压缩</strong>——压缩完你还是不知道&quot;什么时候该用什么&quot;。最近认真研究了一个开源项目 cangjie-skill（仓颉 Skill），它走了另一条路：把一本书、一期播客、一个两小时长视频里沉淀的方法论，拆出来变成 AI Agent 能调用的 Skill 工具包。</p>
<p>一句话：<strong>读完之后，带走一套能调用的方法论，而不是一篇会落灰的总结。</strong></p>
<p>成果长这样：巴菲特致股东信 60+ 年 → 20 个投资判断 Skill；《毛泽东选集》五卷 → 25 个方法 Skill；吴恩达《AI for Everyone》视频课程 → 25 个；连高数上册第一章都被蒸出了 8 个学习 Skill。</p>
<h2>长视频进来的第一步：降维，不是理解</h2>
<p>这个项目处理视频的姿势很聪明：<strong>它根本不去理解视频。</strong>两段式——先由配套工具把视频下载、抽字幕或音频转写，变成纯文本；然后仓颉拿到手的&quot;视频&quot;和一本书没有区别。</p>
<p>为什么这是对的：直接理解视频是多模态难题，理解转写文本是成熟技术。字幕保住了视频里 95% 的方法论信息，剩下 5% 的画面信息对&quot;可调用的方法论&quot;来说基本是噪声。<strong>降维不是妥协，是聚焦。</strong></p>
<h2>七阶段流水线，两处是真灵魂</h2>
<p>RIA-TV++ 七个阶段（RIA 来自拆书法，TV 是三重验证，++ 是面向 Agent 的扩展），展开太长，只说两处灵魂：</p>
<p><strong>晋级门：不是所有内容都配变成 Skill。</strong>候选方法论先过证据检验（原文撑不撑得住），再算一笔账：这个内容的使用价值，值不值得为它增加一个独立入口的路路成本？不值就降级为背景材料。宁缺毋滥是执行出来的，不是喊出来的。</p>
<p><strong>诱饵题：给每个 Skill 埋测试。</strong>设计用例时故意问一些&quot;听起来相关但不该触发这个 Skill&quot;的问题，看它会不会上钩；外加跨 Skill 混淆测试——两个相近的 Skill，Agent 能不能选对。测不过，整个回炉重建。这一步把&quot;看起来能用&quot;和&quot;真的能用&quot;区分开——大多数&quot;AI 帮我读书&quot;的工具，缺的就是这个。</p>
<h2>和一次性工具拉开差距的地方</h2>
<p>v2.5.0 把 Capability Bundle 定为唯一事实源，之后的事才见工程功力：源内容更新了（作者发续集、书出新版），走源 diff + 影响分析，只对受影响的能力卡打事务性补丁；你手改过的地方会被检测到、拒绝盲目覆盖；改坏了有快照回滚。</p>
<p><strong>把 Skill 当持续演进的资产，不当一次性产物。</strong>大多数同类工具生成完就结束了，没有&quot;维护&quot;这个概念。</p>
<p>生态也咬合得清楚：nuwa-skill 蒸馏人（马斯克 Skill、巴菲特 Skill），仓颉蒸馏内容，darwin-skill 让 Skill 进化——各管一段，互相引用。</p>
<h2>冷水也得泼</h2>
<p><strong>版权是悬着的剑。</strong>蒸馏公有领域问题不大，整本蒸别人在售的书并分发，内容和人格权益的边界是模糊的。<strong>字幕质量是天花板</strong>——转写错误直接污染蒸馏源头，垃圾进垃圾出，没有任何后置补救。口语内容方法论密度低，两小时视频可能只有二十分钟干货，淘汰率高是特性不是缺陷。</p>
<p>所以我的用法建议：蒸馏你自己拥有、你反复要用的东西——你的领域的经典、你反复回看的长视频。工具在 GitHub 搜 cangjie-skill，MIT 协议。</p>
<p><strong>聊两句</strong>：如果只能选一本，你想把哪本书蒸成 Skill？评论区写下书名+理由，点赞最高的那本，我下期实际蒸一遍，全程记录出多少个 Skill、质量怎么样。我置顶我的候选（《这样读书就够了》，就冲它的 RIA 方法论本身）。</p>
<p>往期全套在主页：LVS、双模型、ESP8266、PDF 转 EPUB、Cursor 三课、gh、PoC/MVP 顺序论——这个系列叫「把复杂东西拆明白」。</p>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-10-09T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">仓颉 Skill：长视频先降维成文本，再榨出方法论</title>
    <id>https://www.fen9pi.cn/posts/cangjie-video-skill/</id>
    <link href="https://www.fen9pi.cn/posts/cangjie-video-skill/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
上周写过仓颉 Skill（cangjie-skill）的整体架构。这个项目最近更新到 v2.5.0，README 里专门开了一个&quot;视频蒸馏区&quot;——吴恩达《AI for Everyone》视频课程蒸出了 25 个 skill，Loop Engineering 长视频合集蒸出 8 个。</p>
<p>这篇单独拆一件事：<strong>一个两三个小时的 B 站/YouTube 长视频，是怎么变成一套能在 Agent 里调用的 skill 的。</strong></p>
<p>先给结论：整个过程里，&quot;视频&quot;其实只出现在第一步。仓颉 Skill 的聪明之处在于，它根本不去理解视频——<strong>先把视频降维成文本，再把文本里的方法论榨出来。</strong></p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
上周写过仓颉 Skill（cangjie-skill）的整体架构。这个项目最近更新到 v2.5.0，README 里专门开了一个&quot;视频蒸馏区&quot;——吴恩达《AI for Everyone》视频课程蒸出了 25 个 skill，Loop Engineering 长视频合集蒸出 8 个。</p>
<p>这篇单独拆一件事：<strong>一个两三个小时的 B 站/YouTube 长视频，是怎么变成一套能在 Agent 里调用的 skill 的。</strong></p>
<p>先给结论：整个过程里，&quot;视频&quot;其实只出现在第一步。仓颉 Skill 的聪明之处在于，它根本不去理解视频——<strong>先把视频降维成文本，再把文本里的方法论榨出来。</strong></p>
<ul>
<li>GitHub：https://github.com/kangarooking/cangjie-skill</li>
<li>作者：袋鼠帝（kangarooking），AI Top 公众号「袋鼠帝 AI 客栈」主理人</li>
<li>协议：MIT，v2.5.0</li>
</ul>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-09-15T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">40+个Go语言专用技能包，AI写代码错误率下降41%</title>
    <id>https://www.fen9pi.cn/posts/cc-skills-golang-intro/</id>
    <link href="https://www.fen9pi.cn/posts/cc-skills-golang-intro/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<blockquote>
<p>不是让AI随便写Go，而是让它按专家规范写。</p>
</blockquote>
<hr>
<h2>问题</h2>
<p>AI写Go代码，能用，但不够专业。</p>
<ul>
<li>错误处理不符合Go惯例</li>
<li>并发模式用得不对</li>
<li>测试覆盖率低</li>
<li>性能优化不知道从哪下手
&quot;
<strong>AI会写代码，但不会写&quot;Go的方式&quot;。</strong></li>
</ul>
<hr>
<h2>cc-skills-golang 是什么</h2>
<p>samber开源的Go语言专用Agent Skills集合——</p>]]></summary>
    <content type="html"><![CDATA[
<blockquote>
<p>不是让AI随便写Go，而是让它按专家规范写。</p>
</blockquote>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-07-06T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">CI/CD 到底是什么：一条管道，七道工序，127 倍的交付差距</title>
    <id>https://www.fen9pi.cn/posts/ci-cd/</id>
    <link href="https://www.fen9pi.cn/posts/ci-cd/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
CI/CD 这三个字母被说烂了。招聘要求里人人都会写，但真问一句&quot;持续交付和持续部署差在哪&quot;，能答清的不多。</p>
<p>Fortinet 的网络安全术语库有一篇讲 CI/CD 的科普文，写得很系统——从概念、数据、实施步骤到安全防护都有。这篇把它拆开揉碎，配上几张图，一次讲明白。</p>
<hr>
<h2>一、CI 和 CD，其实是两件事</h2>
<p>CI/CD 是一种软件开发方法论：把开发过程中<strong>集成、测试、部署</strong>三个阶段自动化，让频繁的代码变更能被可靠地测试、验证、上线。</p>
<p>拆开看：</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
CI/CD 这三个字母被说烂了。招聘要求里人人都会写，但真问一句&quot;持续交付和持续部署差在哪&quot;，能答清的不多。</p>
<p>Fortinet 的网络安全术语库有一篇讲 CI/CD 的科普文，写得很系统——从概念、数据、实施步骤到安全防护都有。这篇把它拆开揉碎，配上几张图，一次讲明白。</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-09-08T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Claude Code 的 13 个插件：从 PR 审查到安全守护的完整生态</title>
    <id>https://www.fen9pi.cn/posts/claude-code-13-plugins/</id>
    <link href="https://www.fen9pi.cn/posts/claude-code-13-plugins/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="Claude Code 的 13 个插件"></p>
<blockquote>
<p><strong>Claude Code 的 plugins/ 目录下目前有 13 个插件。</strong></p>
<p><strong>从 PR 自动审查到功能开发全流程。</strong></p>
<p><strong>从 Git 工作流自动化到实时安全守护。</strong></p>
<p><strong>从插件开发工具包到 Agent SDK 开发。</strong></p>
<p><strong>这是一个完整的生态。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="Claude Code 的 13 个插件"></p>
<blockquote>
<p><strong>Claude Code 的 plugins/ 目录下目前有 13 个插件。</strong></p>
<p><strong>从 PR 自动审查到功能开发全流程。</strong></p>
<p><strong>从 Git 工作流自动化到实时安全守护。</strong></p>
<p><strong>从插件开发工具包到 Agent SDK 开发。</strong></p>
<p><strong>这是一个完整的生态。</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-09T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">设个目标，让它自己跑完</title>
    <id>https://www.fen9pi.cn/posts/claude-code-goal-feature/</id>
    <link href="https://www.fen9pi.cn/posts/claude-code-goal-feature/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<p>&quot;</p>
<blockquote>
<p>别再每轮都问&quot;做到哪了&quot;。</p>
</blockquote>
<hr>
<h2>痛点</h2>
<p>让Claude Code重构一个模块。</p>
<p>第一轮：你说&quot;重构用户服务&quot;</p>
<p>它改了三处，你看了下：&quot;继续&quot;</p>
<p>第二轮：它又改了五处，你：&quot;继续&quot;</p>
<p>第三轮：你去倒了杯水，回来忘了做到哪了：&quot;嗯？到哪了？&quot;</p>
<p>再过几轮，你疲惫了：&quot;算了，差不多了吧&quot;</p>]]></summary>
    <content type="html"><![CDATA[
<p>&quot;</p>
<blockquote>
<p>别再每轮都问&quot;做到哪了&quot;。</p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-02T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 编程新范式：让 Fable 5 做大脑，Grok 4.5 做执行工</title>
    <id>https://www.fen9pi.cn/posts/claude-code-grok-orchestrator-article/</id>
    <link href="https://www.fen9pi.cn/posts/claude-code-grok-orchestrator-article/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>引言</h2>
<p>想象一下这个场景：</p>
<p>你是一个软件团队的 Tech Lead，手下有两个工程师：</p>
<ul>
<li><strong>架构师</strong>：负责设计、规划、验收，但从不写代码</li>
<li><strong>程序员</strong>：负责写代码、跑命令、改 bug，但不做决策</li>
</ul>
<p>现在，这个场景在 AI 世界里实现了！</p>
<p><strong>Fable 5 做大脑，Grok 4.5 做执行工</strong>，通过 fable-advisor 把 Claude Code 变成 orchestrator，把 Grok CLI 变成 worker。</p>]]></summary>
    <content type="html"><![CDATA[<h2>引言</h2>
<p>想象一下这个场景：</p>
<p>你是一个软件团队的 Tech Lead，手下有两个工程师：</p>
<ul>
<li><strong>架构师</strong>：负责设计、规划、验收，但从不写代码</li>
<li><strong>程序员</strong>：负责写代码、跑命令、改 bug，但不做决策</li>
</ul>
<p>现在，这个场景在 AI 世界里实现了！</p>
<p><strong>Fable 5 做大脑，Grok 4.5 做执行工</strong>，通过 fable-advisor 把 Claude Code 变成 orchestrator，把 Grok CLI 变成 worker。</p>
<p>这不仅是技术的创新，更是 AI 协作模式的范式转移。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-10T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Claude Code GitLab Skill：让 glab 变成 AI 助手</title>
    <id>https://www.fen9pi.cn/posts/claude-glab-skill/</id>
    <link href="https://www.fen9pi.cn/posts/claude-glab-skill/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-2v6c97.jpg" alt="Claude Code 的 GitLab Skill"></p>
<blockquote>
<p><strong>你用 GitLab。</strong></p>
<p><strong>你知道 glab 命令行工具很强大。</strong></p>
<p><strong>但你记不住那些复杂的命令。</strong></p>
<p><strong>claude-glab-skill 让 Claude Code 成为你的 GitLab 专家。</strong></p>
<p><strong>你用自然语言描述任务。</strong></p>
<p><strong>Claude Code 自动调用 glab 命令。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-2v6c97.jpg" alt="Claude Code 的 GitLab Skill"></p>
<blockquote>
<p><strong>你用 GitLab。</strong></p>
<p><strong>你知道 glab 命令行工具很强大。</strong></p>
<p><strong>但你记不住那些复杂的命令。</strong></p>
<p><strong>claude-glab-skill 让 Claude Code 成为你的 GitLab 专家。</strong></p>
<p><strong>你用自然语言描述任务。</strong></p>
<p><strong>Claude Code 自动调用 glab 命令。</strong></p>
</blockquote>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-06-10T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Claude Video：让 Claude &amp;quot;看&amp;quot;懂任何视频</title>
    <id>https://www.fen9pi.cn/posts/claude-video/</id>
    <link href="https://www.fen9pi.cn/posts/claude-video/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：当 Claude 遇上视频</h2>
<p>想象这样一个场景：</p>
<p>你想让 AI 帮你分析一个 YouTube 视频：</p>
<ul>
<li>提取关键信息</li>
<li>总结内容要点</li>
<li>分析视频结构</li>
<li>找出特定时刻的内容
&quot;
<strong>问题来了</strong>：Claude 可以阅读网页、运行脚本、浏览代码库，但它不能&quot;看&quot;视频。</li>
</ul>
<p>你只能：</p>
<ul>
<li>手动观看视频</li>
<li>复制视频链接，希望 Claude 能从标题猜测内容</li>
<li>使用不完整的转录文本，丢失 90% 的视觉信息</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：当 Claude 遇上视频</h2>
<p>想象这样一个场景：</p>
<p>你想让 AI 帮你分析一个 YouTube 视频：</p>
<ul>
<li>提取关键信息</li>
<li>总结内容要点</li>
<li>分析视频结构</li>
<li>找出特定时刻的内容
&quot;
<strong>问题来了</strong>：Claude 可以阅读网页、运行脚本、浏览代码库，但它不能&quot;看&quot;视频。</li>
</ul>
<p>你只能：</p>
<ul>
<li>手动观看视频</li>
<li>复制视频链接，希望 Claude 能从标题猜测内容</li>
<li>使用不完整的转录文本，丢失 90% 的视觉信息</li>
</ul>
<p><strong>如果 Claude 能真正&quot;看&quot;视频呢？</strong></p>
<p><strong>Claude Video</strong> 正是这样的工具：让 Claude 能够&quot;看&quot;任何视频，提取帧、转录音频，将所有视觉和听觉信息交给 Claude 分析。</p>
<p>今天，我们就来分析这个革命性的开源项目。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-28T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Cloudflare 开源 27B 决策模型：不写字，只出概率</title>
    <id>https://www.fen9pi.cn/posts/clef-decision-model/</id>
    <link href="https://www.fen9pi.cn/posts/clef-decision-model/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<p>让 LLM 做判断，是件又慢又悬的事：你问「这条工单该分给谁」，它先写三百字分析，再小心翼翼吐出一个名字，你还得写正则去抠——抠错了就崩。Cloudflare 最近开源了个不一样的玩意儿：Clef，27B 参数的多模态<strong>决策模型</strong>，不写一个字，一次前向传播，直接把你所有问题的每个选项的概率都算出来。</p>
<p>Apache-2.0 协议，权重挂在 HuggingFace 上，开源一周社区已经出了 12 个量化版本。这个热度说明一件事：把「判断」从生成式 LLM 里拆出来，不是某个团队的怪想法，是个正在成形的赛道——之前拆过的 Laya、Jev 走的都是这条路，现在 Cloudflare 也下场了。</p>]]></summary>
    <content type="html"><![CDATA[
<p>让 LLM 做判断，是件又慢又悬的事：你问「这条工单该分给谁」，它先写三百字分析，再小心翼翼吐出一个名字，你还得写正则去抠——抠错了就崩。Cloudflare 最近开源了个不一样的玩意儿：Clef，27B 参数的多模态<strong>决策模型</strong>，不写一个字，一次前向传播，直接把你所有问题的每个选项的概率都算出来。</p>
<p>Apache-2.0 协议，权重挂在 HuggingFace 上，开源一周社区已经出了 12 个量化版本。这个热度说明一件事：把「判断」从生成式 LLM 里拆出来，不是某个团队的怪想法，是个正在成形的赛道——之前拆过的 Laya、Jev 走的都是这条路，现在 Cloudflare 也下场了。</p>
<h2>先看它解决什么问题</h2>
<p>回到第一性：你的业务里大量环节根本不需要「写」，只需要「判」。</p>
<p>工单分派，判个类目；内容审核，判个真假；智能路由，判走哪条链路；发票处理，判要不要人工介入。这些任务现在的主流做法是拿通用 LLM 生成文本再解析，三个毛病：</p>
<ul>
<li><strong>慢</strong>。生成几百 token 才能落到那个词上，延迟下不来</li>
<li><strong>脆</strong>。输出格式飘一下，解析就炸，然后你开始写重试逻辑</li>
<li><strong>贵</strong>。判断一个布尔值，付的是写三百字的 token 钱</li>
</ul>
<p>Clef 的做法是把这些任务全部收进一个「问题 schema」：你声明要问什么、每个问题的候选选项是什么，模型吐出来的就是每个选项的 logit，softmax 之后直接是概率。没有自由文本，没有解析，没有幻觉的空间——它想幻觉都没地方。</p>
<p>顺带说，它的 README 和文档是合格线以上的：问题类型、延迟、部署方式、限制，第一屏都能找到。这种项目值得往下看。</p>
<h2>主执行链路：一次前向发生了什么</h2>
<div class="language-mermaid line-numbers-mode" data-highlighter="shiki" data-ext="mermaid" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-mermaid"><span class="line"><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">flowchart</span><span style="--shiki-light:#4078F2;--shiki-dark:#61AFEF"> TD</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    A</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"状态输入：文本 · JSON · 图片 · 视频&#x3C;br/>+ 问题 schema（noul / choice / score）"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD"> --></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> B</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"Qwen3.8-27B 主干&#x3C;br/>含视觉编码器"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    B </span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">--></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> C</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"联合模式头 joint schema head&#x3C;br/>小 Transformer 读取最终隐状态"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    C </span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">--></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> D</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"所有问题所有选项的 logits"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    D </span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">--></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> E</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"softmax → 概率&#x3C;br/>一次前向，零文字生成"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>拆开说人话：主干是个正经的多模态大模型（Qwen3.8-27B post-train 而来，视觉编码器带着），负责把文本、JSON、图片、视频混着编码成证据。真正的巧思在后面那个<strong>联合模式头</strong>——一个小 transformer 头，读主干的最终隐状态，把证据路由到每个问题上，并且<strong>联合</strong>打分所有选项。</p>
<p>「联合」是关键词。你问三个问题（是不是发票、要不要人工、优先级多高），它不是跑三遍，一遍全出，而且问题之间的关联被保留。中位延迟 209ms——这是 27B 模型的数，Flash 变体压到 38.8ms。</p>
<h2>三种问题类型，就是它的全部词汇表</h2>
<p>设计上克制得漂亮，只有三类：</p>
<ul>
<li><strong>noul</strong>：真假判断。是不是垃圾内容、这条告警是不是误报</li>
<li><strong>choice</strong>：命名选项分类。工单分给售后/研发/销售，路由走 A 链还是 B 链</li>
<li><strong>score</strong>：有序打分。风险等级 1-5，内容质量排序</li>
</ul>
<p>没有第四类。想让它写摘要、写代码、写情书？出门左转找生成模型。这种「不贪」恰恰是它能快、能稳的原因。</p>
<p>实测数字拿得出手：MMLU 90.3，BFCL 98.5；工作流场景里发票处理主行动准确率 86.2，客服分派精确行动 76.3。最后一个数不算惊艳，但在真实业务噪声里做到的，比刷榜含金量高。</p>
<h2>架构与部署边界</h2>
<div class="language-mermaid line-numbers-mode" data-highlighter="shiki" data-ext="mermaid" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-mermaid"><span class="line"><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">flowchart</span><span style="--shiki-light:#4078F2;--shiki-dark:#61AFEF"> TD</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    A</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"主干 27.36B · BF16&#x3C;br/>Qwen3.8-27B post-train"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD"> --></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> B</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"joint schema head&#x3C;br/>证据路由 + 联合打分"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    B </span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">--></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> C</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"输入上限 16384 tokens&#x3C;br/>max_state_tokens 可调"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    C </span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">--></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> D</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"部署面：vLLM · SGLang&#x3C;br/>Docker Model Runner · HF"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span>
<span class="line"><span style="--shiki-light:#E45649;--shiki-dark:#E06C75">    D </span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">--></span><span style="--shiki-light:#E45649;--shiki-dark:#E06C75"> E</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">[</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379">"生态：Clef-Flash 38.8ms&#x3C;br/>12 个社区量化版"</span><span style="--shiki-light:#A626A4;--shiki-dark:#C678DD">]</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>硬件门槛要直说</strong>：权重 54.7GB（分片 safetensors），官方测试环境单张 H200。个人想玩，走社区量化版或者等 Clef-Flash 的小卡方案；企业有 A100/H100 存量的，这就是个顺手活。API 兼容 Jev/SystemOne 协议，<code>systemone</code> 函数直接吃 POST 请求体——已经在用 Jev 生态的，迁移成本接近零。</p>
<p><strong>配置边界</strong>：核心工作量在 schema 设计上——问题怎么问、选项怎么定，决定了上限。这跟提示词工程是两回事，更像数据字典设计，写惯了 PRD 的人反而上手快。</p>
<h2>扩展点和风险点</h2>
<p><strong>能长出来的方向</strong>：Flash 变体做实时线上判断（38.8ms 够放进同步链路）；量化版往 4090 级别下放；配套的决策指数排行榜说明 Cloudflare 想定义这个品类的评测标准——平台级野心。</p>
<p><strong>风险也直说</strong>：一，它是专用件，复杂推理、开放式分析别指望它，硬塞就是用错工具；二，schema 设计是新的工程债，问题设计不好，概率再准也没用；三，发布还早，配套生态（评测、最佳实践、踩坑文档）都在裸奔期，先进场的都在当小白鼠。</p>
<p>我的判断：如果你的系统里有超过三个「其实就是个分类」却让 LLM 写作文的环节，Clef 值得立刻建个评测集试一把——延迟和稳定性收益是立竿见影的。反之，判断量小、不在关键路径上的，通用模型加结构化输出也够，别为了用新锤子满世界找钉子。</p>
<p>正在做工作流路由的朋友会需要这篇，转给他省一次技术选型的弯路。</p>
<p>模型地址：https://huggingface.co/Cloudflare/clef（Apache-2.0，配套决策指数排行榜）</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-10-02T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">CLIProxyAPI：让订阅账号变身 API，AI 编程零成本</title>
    <id>https://www.fen9pi.cn/posts/cliproxyapi/</id>
    <link href="https://www.fen9pi.cn/posts/cliproxyapi/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="CLIProxyAPI"></p>
<blockquote>
<p><strong>Claude Code、Cursor、Cline 这些 AI 编程工具都要 API Key？</strong></p>
<p><strong>每个月几百上千的 API 费用让人心疼？</strong></p>
<p><strong>明明已经有 ChatGPT Plus、Claude Pro 订阅，为什么还要重复付费？</strong></p>
<p><strong>CLIProxyAPI 的答案：</strong></p>
<p><strong>把订阅账号通过 OAuth 转成本地 API，零成本使用 AI 编程工具。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1558494949-ef010cbdcc31-40sbgd.jpg" alt="CLIProxyAPI"></p>
<blockquote>
<p><strong>Claude Code、Cursor、Cline 这些 AI 编程工具都要 API Key？</strong></p>
<p><strong>每个月几百上千的 API 费用让人心疼？</strong></p>
<p><strong>明明已经有 ChatGPT Plus、Claude Pro 订阅，为什么还要重复付费？</strong></p>
<p><strong>CLIProxyAPI 的答案：</strong></p>
<p><strong>把订阅账号通过 OAuth 转成本地 API，零成本使用 AI 编程工具。</strong></p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-07-13T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">从碎片化到闭环：一年前后 AI 开发的进化</title>
    <id>https://www.fen9pi.cn/posts/closed-loop-dev/</id>
    <link href="https://www.fen9pi.cn/posts/closed-loop-dev/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：一个真实的进化故事</h2>
<p>一年前，我开发 iOS app 的基本流程是：</p>
<ol>
<li>我自己用 Xcode 新建项目</li>
<li>然后 Cursor/Claude Code 打开对应的项目表达需求开发</li>
<li>在 Xcode 里构建和测试，也经常要从 Xcode 中复制报错信息给 coding agent</li>
<li>测试完成后，制作宣传图，制作隐私协议链接，让 agent 写应用描述，复制和添加到 AppStore Connect 发布</li>
</ol>
<p><strong>典型场景</strong>：</p>
<ul>
<li>在 Xcode 和 Coding Agent 之间来回切换</li>
<li>手动复制报错信息</li>
<li>手动创建素材</li>
<li>手动填写表单&quot;</li>
<li><strong>我像是一个&quot;工具搬运工&quot;</strong></li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：一个真实的进化故事</h2>
<p>一年前，我开发 iOS app 的基本流程是：</p>
<ol>
<li>我自己用 Xcode 新建项目</li>
<li>然后 Cursor/Claude Code 打开对应的项目表达需求开发</li>
<li>在 Xcode 里构建和测试，也经常要从 Xcode 中复制报错信息给 coding agent</li>
<li>测试完成后，制作宣传图，制作隐私协议链接，让 agent 写应用描述，复制和添加到 AppStore Connect 发布</li>
</ol>
<p><strong>典型场景</strong>：</p>
<ul>
<li>在 Xcode 和 Coding Agent 之间来回切换</li>
<li>手动复制报错信息</li>
<li>手动创建素材</li>
<li>手动填写表单&quot;</li>
<li><strong>我像是一个&quot;工具搬运工&quot;</strong></li>
</ul>
<p>而现在，开发 Mac app 时：</p>
<p><strong>我所有开启项目、构建、测试，甚至应用的打包，素材的设计，以及表单的填写，都全部在 Claude Code 闭环了。</strong></p>
<p><strong>浏览器操作也是它自主进行的，我唯一的作用是表达我想要的产品功能，以及帮他登录下 AppStore Connect 的账号。</strong></p>
<p><strong>典型场景</strong>：</p>
<ul>
<li>在 Claude Code 中完成所有工作</li>
<li>自动构建测试</li>
<li>自动设计素材</li>
<li>自动填写表单</li>
<li><strong>我像是一个&quot;产品经理&quot;</strong></li>
</ul>
<p>这不仅仅是效率的提升，这是工作范式的根本性变革。</p>
]]></content>
    <category term="方法论"/>
    <published>2026-08-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Cloud Document Converter：飞书文档变 Markdown</title>
    <id>https://www.fen9pi.cn/posts/cloud-document-converter/</id>
    <link href="https://www.fen9pi.cn/posts/cloud-document-converter/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="Cloud Document Converter"></p>
<blockquote>
<p><strong>如何将飞书文档转换为 Markdown？</strong></p>
<p><strong>如何批量导出飞书文档为本地文件？</strong></p>
<p><strong>Cloud Document Converter：1.2k Stars 的浏览器扩展</strong></p>
<p><strong>支持下载/复制飞书文档为 Markdown，Chrome/Edge/Firefox 全平台</strong></p>
<p><strong>一个解决飞书文档导出痛点的开源工具</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="Cloud Document Converter"></p>
<blockquote>
<p><strong>如何将飞书文档转换为 Markdown？</strong></p>
<p><strong>如何批量导出飞书文档为本地文件？</strong></p>
<p><strong>Cloud Document Converter：1.2k Stars 的浏览器扩展</strong></p>
<p><strong>支持下载/复制飞书文档为 Markdown，Chrome/Edge/Firefox 全平台</strong></p>
<p><strong>一个解决飞书文档导出痛点的开源工具</strong></p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-07-15T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">中移铁通智能插座复活记：给一块没有 APP 的 ESP8266 硬件重写固件</title>
    <id>https://www.fen9pi.cn/posts/cmpower-w1/</id>
    <link href="https://www.fen9pi.cn/posts/cmpower-w1/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
家里有没有这种设备：运营商送的智能插座，厂商的 APP 停服了，插座本身好好的，继电器能吸合能断开，就是没人管它了——一块标准的&quot;云僵尸&quot;硬件。</p>
<p>CMPOWER W1 就是这么个东西，中移铁通的智能插座，基于乐鑫 ESP8266。作者 Slaven 干的事很干脆：<strong>官方 APP 没了，那就重写一版固件，把这块硬件救活</strong>。固件开源，MQTT 协议控制两个继电器，配任何 MQTT 客户端就能远程控制。</p>
<p>这个项目小，但五脏俱全——配网、协议、状态上报、按键交互一条链路全有，是理解&quot;一个 IoT 设备固件到底由什么组成&quot;的绝佳样本。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
家里有没有这种设备：运营商送的智能插座，厂商的 APP 停服了，插座本身好好的，继电器能吸合能断开，就是没人管它了——一块标准的&quot;云僵尸&quot;硬件。</p>
<p>CMPOWER W1 就是这么个东西，中移铁通的智能插座，基于乐鑫 ESP8266。作者 Slaven 干的事很干脆：<strong>官方 APP 没了，那就重写一版固件，把这块硬件救活</strong>。固件开源，MQTT 协议控制两个继电器，配任何 MQTT 客户端就能远程控制。</p>
<p>这个项目小，但五脏俱全——配网、协议、状态上报、按键交互一条链路全有，是理解&quot;一个 IoT 设备固件到底由什么组成&quot;的绝佳样本。</p>
<h2>一、项目身份</h2>
<p><strong>CMPOWER_W1</strong> 是为中移铁通智能插座（型号 CMPOWER W1）重新开发的开源固件。</p>
<p><strong>一句话说清楚</strong>：</p>
<blockquote>
<p>基于 ESP8266_RTOS_SDK 重写的插座固件，用 MQTT-TCP 控制主/子两个继电器，EspTouch 配网，任何 MQTT 客户端（如 MyMQTT）即可远程控制</p>
</blockquote>
<p><strong>项目地址</strong>：https://github.com/Slaven230101/CMPOWER_W1</p>
<p><strong>技术栈</strong>：ESP8266_RTOS_SDK（release/v3.4）+ MQTT-TCP + EspTouch 配网 + 本地组装脚本烧录（release 提供 <code>xxx_factory.bin</code>，不想编译可以直接刷）。</p>
<p><strong>硬件底子</strong>：ESP8266 WiFi 芯片、两个继电器（主+子）、四组 LED 指示、一个实体按键。原厂价值靠 APP 续着，APP 停服后固件接管一切。</p>
<h2>二、核心思路：协议直连，去掉云依赖</h2>
<p>原厂方案的典型结构是 设备 → 厂商云 → APP。厂商一弃坑，云没了，设备就死了。</p>
<p>这个固件的思路是<strong>把中间的厂商云换成自己可控的 MQTT Broker</strong>：</p>
<ul>
<li>配网用乐鑫标准的 EspTouch（手机把 WiFi 密码通过 UDP 广播&quot;发&quot;给设备，V2 方式）</li>
<li>Broker 默认用公共的 <code>broker.emqx.io</code>，但<strong>支持自定义</strong>——可以接自己的私有 broker</li>
<li>控制端不限定 APP，任何能发布/订阅 MQTT 主题的客户端都行</li>
</ul>
<p>设备从此不再依赖任何一家公司的服务器活命。</p>
<h2>三、主执行链路</h2>
<p></p>
<p>链路上最巧的一环是<strong>自定义数据的双重用途</strong>：EspTouch 配网时那段自定义字符串，格式是 <code>&quot;broker url&quot;:&quot;user string&quot;</code>，一次传输干两件事——告诉设备连哪个 broker，同时定下这个设备专属的主题前缀。</p>
<p>为什么主题前缀重要？因为公共 broker 上所有人共处一个命名空间，如果所有刷了这个固件的设备都订阅 <code>/Slaven/set</code>，你的插座就可能在别人的控制范围里。自定义 user string 让每台设备有自己的主题空间，<strong>这是用命名约定做的隔离，不是鉴权</strong>——这点风险后面细说。</p>
<h2>四、核心模块架构</h2>
<p></p>
<p><strong>主题设计是三个、方向分明</strong>：</p>
<p>| Topic | 设备端 | APP 端 |
|</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-09-23T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Code-Graph-RAG：用知识图谱理解代码库</title>
    <id>https://www.fen9pi.cn/posts/code-graph-rag/</id>
    <link href="https://www.fen9pi.cn/posts/code-graph-rag/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：代码理解的下一维度</h2>
<p><strong>2026-08-12 15:14 GMT+8</strong></p>
<p>理解代码库的方式在进化：</p>
<p><strong>第一代</strong>：grep + 文本搜索</p>
<ul>
<li>找到包含某个关键词的文件</li>
<li>不理解结构，不理解关系</li>
</ul>
<p><strong>第二代</strong>：LSP + 语言服务器</p>
<ul>
<li>理解单个文件的语法</li>
<li>不理解跨文件关系</li>
</ul>
<p><strong>第三代</strong>：RAG + 向量检索</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：代码理解的下一维度</h2>
<p><strong>2026-08-12 15:14 GMT+8</strong></p>
<p>理解代码库的方式在进化：</p>
<p><strong>第一代</strong>：grep + 文本搜索</p>
<ul>
<li>找到包含某个关键词的文件</li>
<li>不理解结构，不理解关系</li>
</ul>
<p><strong>第二代</strong>：LSP + 语言服务器</p>
<ul>
<li>理解单个文件的语法</li>
<li>不理解跨文件关系</li>
</ul>
<p><strong>第三代</strong>：RAG + 向量检索</p>
<ul>
<li>基于语义相似度检索</li>
<li>不理解精确的结构关系</li>
</ul>
<p><strong>第四代</strong>：<strong>知识图谱 + 图遍历</strong></p>
<blockquote>
<p>解析代码库，构建知识图谱，用自然语言查询、编辑、优化代码</p>
</blockquote>
<p><strong>今天介绍 Code-Graph-RAG</strong>：</p>
<blockquote>
<p><strong>Parse code with Tree-sitter, build knowledge graph in Memgraph, query in plain English</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-08-12T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">玩转 Codex 的 10 个高频指令，让 AI 成为你的编程搭档</title>
    <id>https://www.fen9pi.cn/posts/codex-commands/</id>
    <link href="https://www.fen9pi.cn/posts/codex-commands/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-5zebmy.jpg" alt="AI编程助手"></p>
<blockquote>
<p>面对几万行代码，不知从何下手？算法写得一团糟，想重构却怕改出问题？测试用例总是想不全？</p>
</blockquote>
<p>别担心，Codex 的 10 个高频指令，让你的 AI 编程助手成为最强搭档。</p>
<hr>
<h2>为什么需要指令？</h2>
<p>&quot;
就像和同事沟通需要共同语言，和 Codex 协作也需要掌握它的&quot;指令体系&quot;。合理使用这些指令，可以让 Codex：</p>]]></summary>
    <content type="html"><![CDATA[
<p><img src="/images/unsplash/photo-1677442136019-21780ecad995-5zebmy.jpg" alt="AI编程助手"></p>
<blockquote>
<p>面对几万行代码，不知从何下手？算法写得一团糟，想重构却怕改出问题？测试用例总是想不全？</p>
</blockquote>
<p>别担心，Codex 的 10 个高频指令，让你的 AI 编程助手成为最强搭档。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-05-31T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">像专家一样使用 Codex：从「用户」到「驾驭者」的十个习惯</title>
    <id>https://www.fen9pi.cn/posts/codex-expert-habits/</id>
    <link href="https://www.fen9pi.cn/posts/codex-expert-habits/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="Codex 专家"></p>
<blockquote>
<p><strong>普通用户和专家的区别，不是「谁更懂 AI」。</strong></p>
<p><strong>是「谁更懂工程」。</strong></p>
<p>普通用户把 Codex 当聊天机器人。专家把 Codex 当<strong>高强度执行引擎</strong>。</p>
<p>前者问「能不能帮我写个登录页面」，后者说「这是目标、范围、约束、验收标准，请按此执行」。</p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="Codex 专家"></p>
<blockquote>
<p><strong>普通用户和专家的区别，不是「谁更懂 AI」。</strong></p>
<p><strong>是「谁更懂工程」。</strong></p>
<p>普通用户把 Codex 当聊天机器人。专家把 Codex 当<strong>高强度执行引擎</strong>。</p>
<p>前者问「能不能帮我写个登录页面」，后者说「这是目标、范围、约束、验收标准，请按此执行」。</p>
</blockquote>
<h2>习惯 1：结构化提示词，而不是模糊描述</h2>
<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="结构化"></p>
<p><strong>普通用户：</strong></p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>帮我写一个用户登录功能</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div></div></div><p><strong>专家：</strong></p>
<div class="language- line-numbers-mode" data-highlighter="shiki" data-ext style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-"><span class="line"><span>## 目标</span></span>
<span class="line"><span>实现用户登录功能，支持邮箱和手机号</span></span>
<span class="line"><span></span></span>
<span class="line"><span>## 范围</span></span>
<span class="line"><span>- 仅前端实现（后端 API 已存在）</span></span>
<span class="line"><span>- 包含表单验证、错误处理、加载状态</span></span>
<span class="line"><span></span></span>
<span class="line"><span>## 约束</span></span>
<span class="line"><span>- 使用 React + TypeScript</span></span>
<span class="line"><span>- 遵循项目现有代码风格</span></span>
<span class="line"><span>- 必须处理边界情况（空输入、网络错误）</span></span>
<span class="line"><span></span></span>
<span class="line"><span>## 验收标准</span></span>
<span class="line"><span>- [ ] 能正常登录</span></span>
<span class="line"><span>- [ ] 错误时有明确提示</span></span>
<span class="line"><span>- [ ] 通过 TypeScript 类型检查</span></span>
<span class="line"><span>- [ ] 通过 ESLint 检查</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>区别是什么？</strong></p>
<p>普通用户把 Codex 当「魔法」，希望它自己猜。</p>
<p>专家把 Codex 当<strong>工具</strong>，给它明确的输入、输出、约束。</p>
<p><strong>结构化提示词 = 明确的需求 + 边界 + 验收</strong></p>
<p>Codex 不需要猜。Codex 只需要执行。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-02T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">不画草图、不写 PRD，我用 Codex + Figma 一天搞定 UI 设计</title>
    <id>https://www.fen9pi.cn/posts/codex-figma-design/</id>
    <link href="https://www.fen9pi.cn/posts/codex-figma-design/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<p><img src="/images/unsplash/photo-1558655146-9f40138edfeb-5zebmy.jpg" alt="AI设计协作"></p>
<blockquote>
<p>传统 UI 设计流程：产品经理写 PRD → 设计师画草图 → 原型评审 → 视觉设计 → 交互细节 → 开发对接。</p>
</blockquote>
<p><strong>一个页面跑下来，至少一周。</strong></p>
<p>现在有了 Codex + Figma 的组合拳，我一天搞定了 8 个页面的完整设计。</p>
<hr>
<h2>🎯 传统流程的痛点</h2>
<p>在设计团队工作时，最常见的问题是：</p>]]></summary>
    <content type="html"><![CDATA[
<p><img src="/images/unsplash/photo-1558655146-9f40138edfeb-5zebmy.jpg" alt="AI设计协作"></p>
<blockquote>
<p>传统 UI 设计流程：产品经理写 PRD → 设计师画草图 → 原型评审 → 视觉设计 → 交互细节 → 开发对接。</p>
</blockquote>
<p><strong>一个页面跑下来，至少一周。</strong></p>
<p>现在有了 Codex + Figma 的组合拳，我一天搞定了 8 个页面的完整设计。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-05-31T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">当 Vibe Coding 遇上语音：Codex GPTLive 实测</title>
    <id>https://www.fen9pi.cn/posts/codex-gptlive/</id>
    <link href="https://www.fen9pi.cn/posts/codex-gptlive/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/covers/codex-gptlive.png" alt="题图">
&quot;</p>
<h2>前言：当编程遇上&quot;解放双手&quot;</h2>
<p>想象这样一个场景：</p>
<p>你在家里，戴着 AirPods，一边做家务，一边跟你的&quot;编程助手&quot;对话：</p>
<p>&quot;嘿，帮我看看登录功能的代码&quot;
&quot;这里有个 bug，帮我修复一下&quot;
&quot;部署到测试环境&quot;
&quot;跑一下测试&quot;</p>
<p>没有键盘，没有鼠标，甚至不需要看着电脑屏幕。你的&quot;编程助手&quot;会告诉你一切，并执行你的命令。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/covers/codex-gptlive.png" alt="题图">
&quot;</p>
<h2>前言：当编程遇上&quot;解放双手&quot;</h2>
<p>想象这样一个场景：</p>
<p>你在家里，戴着 AirPods，一边做家务，一边跟你的&quot;编程助手&quot;对话：</p>
<p>&quot;嘿，帮我看看登录功能的代码&quot;
&quot;这里有个 bug，帮我修复一下&quot;
&quot;部署到测试环境&quot;
&quot;跑一下测试&quot;</p>
<p>没有键盘，没有鼠标，甚至不需要看着电脑屏幕。你的&quot;编程助手&quot;会告诉你一切，并执行你的命令。</p>
<p>这听起来像科幻小说？不，这是 <strong>Codex GPTLive</strong> 正在实现的现实。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-07-24T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Codex + HyperFrames + Remotion 做视频一周记</title>
    <id>https://www.fen9pi.cn/posts/codex-hyperframes-remotion-week/</id>
    <link href="https://www.fen9pi.cn/posts/codex-hyperframes-remotion-week/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：视频创作的新范式</h2>
<p>传统视频创作流程：</p>
<ul>
<li>写脚本</li>
<li>录制/剪辑</li>
<li>调色/配音</li>
<li>导出/发布</li>
</ul>
<p>这个流程的痛点：</p>
<ul>
<li>需要专业的剪辑技能</li>
<li>调整改动成本高</li>
<li>动效需要手动制作</li>
<li>重复劳动多</li>
</ul>
<p>上周尝试了一个新范式：</p>
<p><strong>用 Codex + HyperFrames + Remotion 做视频。</strong></p>
<p>结果：一周完成了 10 个视频，质量不输专业剪辑，而且所有改动都是代码级别的调整。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：视频创作的新范式</h2>
<p>传统视频创作流程：</p>
<ul>
<li>写脚本</li>
<li>录制/剪辑</li>
<li>调色/配音</li>
<li>导出/发布</li>
</ul>
<p>这个流程的痛点：</p>
<ul>
<li>需要专业的剪辑技能</li>
<li>调整改动成本高</li>
<li>动效需要手动制作</li>
<li>重复劳动多</li>
</ul>
<p>上周尝试了一个新范式：</p>
<p><strong>用 Codex + HyperFrames + Remotion 做视频。</strong></p>
<p>结果：一周完成了 10 个视频，质量不输专业剪辑，而且所有改动都是代码级别的调整。</p>
<p>今天聊聊这个组合为什么有效，以及如何复制这个流程。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-08-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Codex 的图像 Agent 专用 UI：从聊天流到专业预览</title>
    <id>https://www.fen9pi.cn/posts/codex-image-ui/</id>
    <link href="https://www.fen9pi.cn/posts/codex-image-ui/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：图像 Agent 的交互困境</h2>
<p>用过 GPT Image 2.0 或其他图像生成 Agent 的都知道：</p>
<p><strong>聊天流不是为图像设计的。</strong></p>
<p>你让它生成 4 张图片，它返回来 4 张大图 + 一堆文案。你想看清楚某张图，得在聊天流里上下滚动，还得手动把文案挪开。
&quot;
你想让 AI 修改某张图，得先说清楚是哪张——&quot;第三张那个&quot;——然后等着它重新生成。</p>
<p>如果你想批量修改几张图，那就更麻烦了。你得一个一个地描述，一个一个地等。</p>
<p><strong>核心问题</strong>：图像 Agent 需要的是专门的预览和编辑界面，不是聊天流。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：图像 Agent 的交互困境</h2>
<p>用过 GPT Image 2.0 或其他图像生成 Agent 的都知道：</p>
<p><strong>聊天流不是为图像设计的。</strong></p>
<p>你让它生成 4 张图片，它返回来 4 张大图 + 一堆文案。你想看清楚某张图，得在聊天流里上下滚动，还得手动把文案挪开。
&quot;
你想让 AI 修改某张图，得先说清楚是哪张——&quot;第三张那个&quot;——然后等着它重新生成。</p>
<p>如果你想批量修改几张图，那就更麻烦了。你得一个一个地描述，一个一个地等。</p>
<p><strong>核心问题</strong>：图像 Agent 需要的是专门的预览和编辑界面，不是聊天流。</p>
<p>今天介绍 Codex 新推出的<strong>图像 Agent 专用 UI 模式</strong>，专门解决这个问题。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-08-10T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Codex 进手机：OpenAI 的「超级 App」野心，终于藏不住了</title>
    <id>https://www.fen9pi.cn/posts/codex-mobile/</id>
    <link href="https://www.fen9pi.cn/posts/codex-mobile/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="手机上的 Codex"></p>
<blockquote>
<p>你不再需要坐在电脑前盯着 AI 干活。你的手机，成了 AI 的遥控器。</p>
</blockquote>
<p>今天，OpenAI 做了一件看起来很小、但意味深长的事：</p>
<p><strong>把 Codex 搬进了 ChatGPT 手机 App。</strong></p>
<p>iOS 和安卓同步开启 preview，所有用户都能用——包括免费版和最低价的 Go 套餐。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="手机上的 Codex"></p>
<blockquote>
<p>你不再需要坐在电脑前盯着 AI 干活。你的手机，成了 AI 的遥控器。</p>
</blockquote>
<p>今天，OpenAI 做了一件看起来很小、但意味深长的事：</p>
<p><strong>把 Codex 搬进了 ChatGPT 手机 App。</strong></p>
<p>iOS 和安卓同步开启 preview，所有用户都能用——包括免费版和最低价的 Go 套餐。</p>
<p>这不是「在手机上写代码」。手机只是一个远程窗口：真正的 Codex 还是在你的 Mac、devbox 或者远程服务器上跑。</p>
<p>你在地铁上，打开 ChatGPT App，就能看到 Codex 跑到哪一步了。你能审一眼它改的 diff、看一眼测试结果，批准下一步，或者临时换个方向。</p>
<p>文件、凭证、权限都留在原来那台机器上，不上传到手机。</p>
<p><strong>这看起来是一个功能更新。但实际上，这是 OpenAI 「超级 App」战略的关键一环。</strong></p>
<h2>为什么是现在？</h2>
<p>OpenAI 自己公布的数字：<strong>Codex 每周活跃用户已经过 400 万。</strong></p>
<p>这是一个临界点。</p>
<p>当 400 万人开始用 AI 写代码，一个行为模式开始变得明显：<strong>AI 跑的任务越来越长。</strong></p>
<p>以前，AI 帮你写一个函数，几秒钟就完事。你在电脑前等着，没问题。</p>
<p>现在，AI 帮你重构一个模块、写一堆测试、修复一堆 Bug——这些任务可能跑几十分钟、甚至几小时。</p>
<p><strong>这个时候，人坐在电脑前盯着就很傻。</strong></p>
<p>你需要的是：随手能看一眼、能拍板、能干预的能力。</p>
<p><strong>这就是手机端的核心价值：不是替代电脑，是解放你。</strong></p>
<p>你可以离开电脑。Codex 继续跑。你有空的时候，掏出手机瞄一眼，批准下一步，或者调个方向。</p>
<p><strong>这是「AI 时代的工作方式」。</strong></p>
<h2>技术上怎么实现的？</h2>
<p>这里有个关键细节：<strong>secure relay 中继。</strong></p>
<p>跑着 Codex 的机器（你的 Mac、devbox、远程服务器）不需要直接暴露在公网上。它通过 OpenAI 的中继层和你的手机连接。</p>
<p><strong>这意味着什么？</strong></p>
<p>第一，<strong>安全。</strong> 你的机器不直接暴露公网 IP，攻击面小。</p>
<p>第二，<strong>可达。</strong> 你在哪台设备登录 ChatGPT，会话状态就跟到哪里。你在家用电脑，出门用手机，完全无缝切换。</p>
<p>第三，<strong>隐私。</strong> 文件、凭证都留在原来那台机器上，不上传到手机。</p>
<p>OpenAI 没有说太多技术细节，但这个架构很清晰：<strong>手机是控制端，Codex 机器是执行端，中间是 OpenAI 的中继层。</strong></p>
<p>这不是一个简单的功能。这是一个<strong>跨设备的分布式系统</strong>。</p>
<h2>为什么这件事很重要？</h2>
<p>表面上看，这只是「在手机上看 Codex 跑任务」。但深层来看，这是三个战略信号的叠加。</p>
<h3>信号一：长任务是常态</h3>
<p>OpenAI 这么做，本质上是在承认：<strong>AI Agent 跑长任务，已经是主流使用模式。</strong></p>
<p>短任务（几秒、几分钟）在电脑上处理没问题。长任务（几十分钟、几小时）需要跨设备、异步处理。</p>
<p><strong>这是 AI 从「工具」到「协作伙伴」的转变。</strong></p>
<p>工具是你用的时候才开，协作伙伴是它一直在那干活，你需要的时候介入。</p>
<p><strong>长任务意味着 AI 不再是「响应式」的。它是「持续运行」的。</strong></p>
<h3>信号二：ChatGPT 是「超级 App」</h3>
<p>注意一个细节：<strong>OpenAI 没给 Codex 单独做手机 App。它是把 Codex 塞进 ChatGPT 主 App。</strong></p>
<p>这跟他们之前透露过的策略一致：把 ChatGPT、Codex、Atlas 浏览器整合成一个入口。</p>
<p><strong>桌面端是独立的 Codex App。手机端直接合并进 ChatGPT。</strong></p>
<p>为什么？因为手机端的交互模式不一样。</p>
<p>你在手机上，不是「打开一个专门的编程 App」。你是「打开 ChatGPT，然后顺带看一眼 Codex」。</p>
<p><strong>ChatGPT 是入口，Codex 是其中一个能力。</strong></p>
<p>这是「超级 App」的逻辑——所有功能都在一个 App 里，用户不需要在多个 App 之间切换。</p>
<p><strong>长远来看，OpenAI 的野心是：ChatGPT = AI 时代的操作系统。</strong></p>
<h3>信号三：对标 Anthropic</h3>
<p>参照系很明确：<strong>Claude Code。</strong></p>
<p>Anthropic 的 Claude Code 从去年秋天起，就支持手机远程查看和介入正在跑的任务。后面的 Cowork 配套移动端，走的也是类似 dispatch 思路。</p>
<p><strong>Codex 这次不只是追平。它在扩张。</strong></p>
<p>Claude Code 主要是本地环境。Codex 扩到了 devbox、远程企业环境（支持 remote SSH 接入）。</p>
<p><strong>这是 OpenAI 和 Anthropic 的军备竞赛。</strong></p>
<p>双方都在抢同一个东西：<strong>AI 时代的工作流入口。</strong></p>
<p>谁能成为程序员每天打开的第一个 App？谁能成为「AI 写代码」的默认选择？</p>
<h2>现在的限制和未来的可能</h2>
<p>目前有个明显限制：<strong>手机端只能连 macOS 上的 Codex。</strong></p>
<p>Windows 支持据说「很快」。</p>
<p>但这个限制本身很有意思。它说明：<strong>OpenAI 在优先级上，先照顾苹果生态。</strong></p>
<p>为什么？可能是 macOS 的开发者密度高，可能是 Unix 系统好做远程接入，可能是苹果用户付费意愿强。</p>
<p><strong>无论如何，Windows 支持只是时间问题。</strong></p>
<p>更值得思考的是：<strong>未来会怎么演化？</strong></p>
<h3>演化一：多 Agent 协作</h3>
<p>现在手机端只能看一个 Codex 在跑。未来，可能是多个 Agent 并行跑。</p>
<p>你在手机上看到的不是「一个任务进度」，是「一个任务面板」——Agent A 在重构代码、Agent B 在写测试、Agent C 在跑性能分析。</p>
<p>你批准 A，暂停 B，给 C 加个优先级。</p>
<p><strong>这是「项目经理视角」，不是「单任务视角」。</strong></p>
<h3>演化二：跨平台协作</h3>
<p>现在 Codex 主要是写代码。未来，它可能和设计师 Agent、产品经理 Agent 协作。</p>
<p>你在手机上，不仅看到代码进度，还看到设计稿更新、需求文档迭代。</p>
<p><strong>这是「全流程视角」，不是「单一工种视角」。</strong></p>
<h3>演化三：语音介入</h3>
<p>现在你在手机上是看 diff、看测试结果。未来，你可能是直接说话：</p>
<p>「Codex，那个性能优化先停一下，优先处理这个 Bug。」</p>
<p>「把刚才的重构撤回，换个方向。」</p>
<p><strong>这是「对话式控制」，不是「点击式操作」。</strong></p>
<h2>对普通用户意味着什么？</h2>
<p>如果你不是程序员，这件事和你有关系吗？</p>
<p><strong>有关系。</strong></p>
<p>因为这不是「编程工具的升级」。这是「AI 工作方式的升级」。</p>
<p>今天 Codex 在手机上能看代码进度。明天，你的 AI 助手在手机上能干什么？</p>
<ul>
<li>看 AI 帮你写的报告写到哪了</li>
<li>批准 AI 帮你做的数据分析结果</li>
<li>调整 AI 帮你设计的营销方案</li>
</ul>
<p><strong>逻辑是一样的：长任务、跨设备、异步介入。</strong></p>
<p><strong>AI 不是在你用的时候才工作。AI 在后台持续工作，你需要的时候掏出手机看一眼、调一下。</strong></p>
<h2>对开发者意味着什么？</h2>
<p>如果你是开发者，这件事在提醒你三个趋势。</p>
<h3>趋势一：长任务是未来</h3>
<p>你的产品、你的功能，需要考虑「长任务场景」。</p>
<p>用户不是用一次就走。用户可能会让 AI 跑几个小时。</p>
<p>你需要回答：用户怎么知道进度？用户怎么介入？用户怎么控制？</p>
<p><strong>短任务场景已经红海了。长任务场景才是蓝海。</strong></p>
<h3>趋势二：跨设备是标配</h3>
<p>用户不会只在一个设备上用你的产品。</p>
<p>他们在家用电脑，出门用手机，在会议室用平板。</p>
<p>你的产品需要支持：跨设备的状态同步、跨设备的无缝切换、跨设备的安全连接。</p>
<p><strong>「只能在一个设备上用」的产品，已经过时了。</strong></p>
<h3>趋势三：超级 App 是方向</h3>
<p>用户不想装一堆 App。</p>
<p>他们想要一个入口，进去后能用各种 AI 能力——聊天、写代码、做分析、管理任务。</p>
<p><strong>你的产品是独立 App，还是某个「超级 App」里的一个能力？</strong></p>
<p>这不是技术问题。这是战略问题。</p>
<h2>写在最后</h2>
<p>Codex 进手机，看起来是个小功能。但它指向的未来很清晰：</p>
<p><strong>AI 不是「工具」。AI 是「持续运行的协作伙伴」。</strong></p>
<p>你不需要坐在它前面。你不需要盯着它干活。</p>
<p><strong>你在哪，它就在哪。你需要的时候，掏出手机就能看到它、控制它、指导它。</strong></p>
<p>这才是 AI 应该有的样子。</p>
<p>而 OpenAI 和 Anthropic，正在争夺这个「AI 工作流入口」。</p>
<p><strong>谁能成为你每天打开的第一个 App？谁就能定义 AI 时代的工作方式。</strong></p>
<p><em>Codex 进手机不是终点。它是「超级 App」战略的开始。</em></p>
<p>&quot;</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-05-29T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Codex PPT Skill：把文章变成整页图片式 PPT</title>
    <id>https://www.fen9pi.cn/posts/codex-ppt-skill/</id>
    <link href="https://www.fen9pi.cn/posts/codex-ppt-skill/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
AI 生成 PPT 的方案一大堆，但绝大多数走的是&quot;往模板里填文字&quot;的路子——生成的 PPT 一眼就是模板味，版式千篇一律。</p>
<p>Codex PPT Skill 换了个思路：<strong>别填模板了，每一页直接生成一张完整的 16:9 图片</strong>。文字、配色、版式、插图全部由生图模型一次画出来，最后用本地脚本把图片组装成 <code>.pptx</code>。这个项目在 GitHub 拿了两千多 star，作者还专门写过一篇复盘：好的 AI Skill 是调出来的，不是写出来的。</p>
<p>这篇把它的核心思路、完整链路和边界风险拆开讲清楚。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>&quot;
AI 生成 PPT 的方案一大堆，但绝大多数走的是&quot;往模板里填文字&quot;的路子——生成的 PPT 一眼就是模板味，版式千篇一律。</p>
<p>Codex PPT Skill 换了个思路：<strong>别填模板了，每一页直接生成一张完整的 16:9 图片</strong>。文字、配色、版式、插图全部由生图模型一次画出来，最后用本地脚本把图片组装成 <code>.pptx</code>。这个项目在 GitHub 拿了两千多 star，作者还专门写过一篇复盘：好的 AI Skill 是调出来的，不是写出来的。</p>
<p>这篇把它的核心思路、完整链路和边界风险拆开讲清楚。</p>
<h2>一、项目身份</h2>
<p><strong>Codex PPT Skill</strong> 是一个面向 Codex 的 PPT 生成 skill，MIT 协议，也可在 Claude Code、OpenClaw、Hermes Agent 等一切支持 <code>SKILL.md</code> 的 agent 里用——非 Codex 环境需要配一个生图 API（<code>gpt-image-2.5-flare</code> 或任何 OpenAI 兼容接口）。</p>
<p><strong>一句话说清楚</strong>：</p>
<blockquote>
<p>给它一篇文章、报告、论文或课程笔记，它先规划大纲和视觉风格，确认后逐页生成幻灯片图片，最后组装为带演讲备注的 PPTX</p>
</blockquote>
<p><strong>应用方向</strong>：技术文章转分享 PPT、论文转答辩演示稿、课程笔记转课件、商业汇报和产品介绍——凡是需要强视觉统一性的图片式演示文稿。</p>
<p><strong>效果</strong>：每页都是整图生成的 16:9 幻灯片，12 种内置风格（清爽专业、科研答辩、手绘技术解释、麦肯锡、电子墨水杂志……），还能复刻你丢给它的任何参考风格。</p>
<h2>二、核心思路：三步走，每步都先确认</h2>
<p>它和&quot;无脑一键生成&quot;最本质的区别是<strong>阶段化确认</strong>。整个流程被切成三段，每段产出中间产物、等你点头才继续：</p>
<p></p>
<p><strong>为什么这么设计？</strong>一次生成 20 页图片，如果第 15 页才发现风格不对，返工成本是灾难性的。样张机制把&quot;方向性错误&quot;拦在只花一张图的成本时。这正是作者复盘里说的&quot;调出来的 skill&quot;——每个确认点都是真实返工教训换来的。</p>
<p><strong>并发与自检</strong>：样张确认后，一个子 agent 负责一页并发生成，每页生成后自检文字清晰度、风格一致性和内容完整性，发现问题自动返修。整套 20 页的 PPT 并发出图，速度不是逐页串行的二十倍关系但快得多。</p>
<h2>三、核心模块架构</h2>
<p></p>
<p>四个模块各有值得说的细节：</p>
<p><strong>风格系统是三层结构</strong>：内置 12 种风格打底（不会写提示词也能起步，作者最推荐手绘技术解释风）；支持丢参考图/截图/完整 PPT 让 agent 先分析配色版式再复刻；最妙的是个人风格库——生成满意的风格可以存进 <code>~/.codex-ppt-skill/references/</code>，<strong>这个目录在 skill 安装目录之外，更新重装都不丢</strong>，同名时个人风格压过内置风格。风格资产跟着人走，不跟着 skill 走。</p>
<p><strong>生图后端是抽象的双通道</strong>：Codex 环境优先走内置生图（会员订阅覆盖，免配置）；其他环境或需要精确控制分辨率/质量时走 API fallback，默认 2K 16:9，文字多可上 4K（注意 GPT Image 2.5 超过 2560x1440 属实验性）。</p>
<p><strong>组装脚本是最后一公里</strong>：纯本地 Python，把图片按页码顺序装进 PPTX，speech.md 的内容写进每页备注——演示时按演讲者视图就有讲稿。</p>
<h2>四、数据与状态流</h2>
<p></p>
<p>输出结构本身就是状态记录——每个 PPT 一个独立项目目录：<code>origin_image/</code> 放最终采用的页面图（按 slide_01.png 顺序命名，想改哪页直接指着说）、<code>outline.md</code> 是确认过的大纲、<code>speech.md</code> 是讲稿、最后是组装好的 PPTX。<strong>中间产物全部落盘</strong>，任何一个环节想回退或局部修改，都有据可查。</p>
<p>特别提一个能力：<strong>指定图片插入</strong>。可以在大纲里要求某页必须放论文原图、实验结果图、架构图，让页面围绕这些素材适配主题和版式——项目的论文答辩案例（Attention Is All You Need）就展示了把原始架构图和 attention 可视化图嵌进统一风格的整套 PPT。</p>
<h2>五、跨端边界</h2>
<ul>
<li><strong>Codex</strong>：首选环境，内置生图 + 编辑图能力，免 API key</li>
<li><strong>Claude Code / OpenClaw / Hermes Agent</strong>：读 <code>SKILL.md</code> 即可用，需配第三方生图 API 或 OpenAI 兼容接口</li>
<li><strong>OpenClaw</strong> 有专门渠道：ClawHub 一条命令安装（注意 allowlist 要加 <code>codex-ppt</code>）</li>
<li><strong>配置的跨端安全</strong>：API key（<code>~/.codex-ppt-skill/.env</code>）和个人风格库都在 skill 安装目录之外，更新重装 skill 均不丢失</li>
</ul>
<h2>六、配置边界</h2>
<ul>
<li><strong>必须配</strong>：基本零配置起步——Codex 用户开箱即用；非 Codex 环境才需要 .env 里配 API key、base URL、模型名</li>
<li><strong>建议配</strong>：走通常用路线后，<strong>让 AI 帮你把 skill 改成固定偏好</strong>——固定生图后端、固定是否用子 agent、固定输出目录、页数节奏。作者明说了：这个 skill 为了通用性，流程设计得偏复杂（同时兼容内置/API 生图、有无子 agent 两条路），大部分人日常只走其中一条，把别的岔路封掉能显著省心</li>
<li><strong>不要配</strong>：首次使用就上 4K（文字多再上）；实验性分辨率当生产配置</li>
</ul>
<h2>七、扩展点</h2>
<ol>
<li><strong>单页局部修改</strong>：不满意某一页不用整套重来，直接框选标注让 agent 改那一页——局部重绘是生图式 PPT 的刚需能力</li>
<li><strong>风格复刻 + 风格库沉淀</strong>：输入可以是任意截图、PDF、PPTX，风格资产可积累可迁移，越用越像你</li>
<li><strong>姊妹 skill 补可编辑性</strong>：<code>image-to-editable-ppt-skill</code>（同作者）把生成的图片版 PPT 重建为可编辑 PowerPoint——图片式管视觉，可编辑版管二次加工，两个 skill 组成完整链路</li>
<li><strong>生态位</strong>：作者还有 handdrawn-tech-illustrations（中文手绘配图）、awesome-ai-ppt（按 HTML-first/图片生成式/PPTX-native 分类的工作流清单），codex-ppt 在里面就是&quot;图片生成式&quot;路线的代表</li>
</ol>
<h2>八、风险点</h2>
<ol>
<li><strong>页面不可直接编辑</strong>是根本限制。每页是位图，PPTX 里改不了字——需要改文字就重生成该页，或者走姊妹 skill 转可编辑版。强视觉表达和可编辑性，目前只能二选一</li>
<li><strong>生图模型的文字清晰度是老毛病</strong>。整套流程里的自检、返修、4K 选项、样张确认，本质上都在对抗这个问题；文字密集型 PPT（如法务条文、密集数据表）不是它的舒适区</li>
<li><strong>成本随页数线性走</strong>。一页一张整图，20 页就是 20 次生图调用，外加自检返修的额外次数——大页数 PPT 前先算账，样张阶段就锁死风格别中途换</li>
<li><strong>通用性带来的流程复杂度</strong>。作者自己承认：兼容多路线带来不稳定和冗余，多数场景下你应该主动裁剪流程（改 skill 固定偏好）——不改，每次都会在岔路口重新选择</li>
<li><strong>实验性能力依赖</strong>。超 2560x1440 的 4K 输出、第三方中转站的模型/参数支持，都可能踩到服务端限制，关键交付别压在实验性配置上</li>
<li><strong>风格漂移风险</strong>。并发逐页生成时，长 PPT 的后段页面可能与样张风格出现细微不一致——自检会拦一部分，但不是全部，成套导出前人工翻一遍最后一页和第一页的对比</li>
</ol>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-09-23T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Codex Taskboard：嵌入 Codex 的议题面板</title>
    <id>https://www.fen9pi.cn/posts/codex-taskboard/</id>
    <link href="https://www.fen9pi.cn/posts/codex-taskboard/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：议题管理的新范式</h2>
<p><strong>2026-08-13 08:37 GMT+8</strong></p>
<p>管理议题的方式在进化：</p>
<p><strong>第一代</strong>：纸质看板</p>
<ul>
<li>物理卡片</li>
<li>白板或墙面</li>
<li>面对面协作</li>
</ul>
<p><strong>第二代</strong>：SaaS 工具（Jira, Trello, Linear...）</p>
<ul>
<li>云端服务</li>
<li>需要账户</li>
<li>依赖网络</li>
<li>数据在云端</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：议题管理的新范式</h2>
<p><strong>2026-08-13 08:37 GMT+8</strong></p>
<p>管理议题的方式在进化：</p>
<p><strong>第一代</strong>：纸质看板</p>
<ul>
<li>物理卡片</li>
<li>白板或墙面</li>
<li>面对面协作</li>
</ul>
<p><strong>第二代</strong>：SaaS 工具（Jira, Trello, Linear...）</p>
<ul>
<li>云端服务</li>
<li>需要账户</li>
<li>依赖网络</li>
<li>数据在云端</li>
</ul>
<p><strong>第三代</strong>：<strong>本地优先 + AI 集成</strong></p>
<blockquote>
<p>本地优先的数据存储，嵌入 AI 工具，议题管理无缝集成</p>
</blockquote>
<p><strong>今天介绍 Codex Taskboard</strong>：</p>
<blockquote>
<p><strong>一个本地优先的议题面板，可在浏览器中运行，也可嵌入 Codex</strong></p>
</blockquote>
]]></content>
    <category term="AI 工程"/>
    <published>2026-08-13T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Coding-Agent Skill：让 Claude Code 自主写代码</title>
    <id>https://www.fen9pi.cn/posts/coding-agent-wechat/</id>
    <link href="https://www.fen9pi.cn/posts/coding-agent-wechat/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1498050108023-c5249f4df085-40sbgd.jpg" alt="AI 编程助手"></p>
<blockquote>
<p>你是否曾经希望，跟 AI 助手说一句话，它就能自动帮你写完一个完整模块？今天介绍的 Coding-Agent Skill，就是 OpenClaw 里让 Claude Code 自主完成编程任务的利器。</p>
</blockquote>
<h2>什么是 Coding-Agent Skill？</h2>
<p>Coding-Agent 是 OpenClaw 的一个内置技能，它的核心能力是：<strong>把你的一句话指令，委派给系统里的编程 Agent（Claude Code / Codex / Pi）去自动执行</strong>。</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1498050108023-c5249f4df085-40sbgd.jpg" alt="AI 编程助手"></p>
<blockquote>
<p>你是否曾经希望，跟 AI 助手说一句话，它就能自动帮你写完一个完整模块？今天介绍的 Coding-Agent Skill，就是 OpenClaw 里让 Claude Code 自主完成编程任务的利器。</p>
</blockquote>
<h2>什么是 Coding-Agent Skill？</h2>
<p>Coding-Agent 是 OpenClaw 的一个内置技能，它的核心能力是：<strong>把你的一句话指令，委派给系统里的编程 Agent（Claude Code / Codex / Pi）去自动执行</strong>。</p>
<p><img src="/images/unsplash/photo-1629654297299-c8506221ca97-40sbgd.jpg" alt="任务执行引擎"></p>
<p>它不是一个聊天工具，而是一个 <strong>任务执行引擎</strong>——你告诉它做什么，它就在后台默默干活，完成后把结果汇报给你。</p>
<h2>前置准备</h2>
<p><strong>1. 确认 Claude Code 已安装</strong></p>
<div class="language-bash line-numbers-mode" data-highlighter="shiki" data-ext="bash" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-bash"><span class="line"><span style="--shiki-light:#4078F2;--shiki-dark:#61AFEF">claude</span><span style="--shiki-light:#986801;--shiki-dark:#D19A66"> --version</span></span>
<span class="line"><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic"># 应该输出类似：2.1.152 (Claude Code)</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div></div></div><p>如果未安装，执行：</p>
<div class="language-bash line-numbers-mode" data-highlighter="shiki" data-ext="bash" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-bash"><span class="line"><span style="--shiki-light:#4078F2;--shiki-dark:#61AFEF">npm</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379"> install</span><span style="--shiki-light:#986801;--shiki-dark:#D19A66"> -g</span><span style="--shiki-light:#50A14F;--shiki-dark:#98C379"> @anthropic-ai/claude-code</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div></div></div><p><strong>2. 在 OpenClaw 对话中直接使用</strong></p>
<p>无需额外配置，OpenClaw 会自动识别并加载 coding-agent skill。</p>
<p><img src="/images/unsplash/photo-1607799279861-4dd421887fb3-40sbgd.jpg" alt="开发环境"></p>
<h2>核心用法：三步走</h2>
<h3>第一步：告诉 AI 你要做什么</h3>
<p>直接用自然语言描述你的需求，比如：
&quot;</p>
<ul>
<li>&quot;用 Claude Code 帮我写一个用户登录接口&quot;</li>
<li>&quot;让 Claude Code 审查一下 src/auth/ 目录的代码&quot;</li>
<li>&quot;用 Claude Code 把 utils 模块重构成 async/await&quot;</li>
</ul>
<h3>第二步：AI 自动执行</h3>
<p>OpenClaw 会在后台启动 Claude Code，传入你的任务描述。执行时你不需要做任何事。</p>
<p><img src="/images/unsplash/photo-1555099962-4199c345e5dd-40sbgd.jpg" alt="自动化执行"></p>
<h3>第三步：查看结果</h3>
<p>任务完成后，AI 会主动告诉你结果。如果是长时间任务，你也可以随时问：&quot;跑完了吗？&quot;来查看进度。</p>
<h2>实战场景</h2>
<h3>场景 1：创建新项目</h3>
<p><strong>你说：</strong> &quot;用 Claude Code 在 ~/Projects 目录下创建一个 React + TypeScript 的 Todo App&quot;</p>
<p><strong>AI 做的事：</strong></p>
<ul>
<li>自动创建项目目录</li>
<li>初始化 React + TypeScript 项目</li>
<li>实现 Todo 的增删改查功能</li>
<li>完成后汇报结果</li>
</ul>
<h3>场景 2：代码审查</h3>
<p><strong>你说：</strong> &quot;让 Claude Code 帮我审查一下后端代码的安全性&quot;</p>
<p><img src="/images/unsplash/photo-1605379399642-870262d3d051-40sbgd.jpg" alt="代码审查"></p>
<p><strong>AI 做的事：</strong></p>
<ul>
<li>扫描指定目录下的代码</li>
<li>识别安全漏洞（SQL注入、XSS、认证缺陷等）</li>
<li>生成审查报告</li>
</ul>
<h3>场景 3：批量重构</h3>
<p><strong>你说：</strong> &quot;用 Claude Code 把项目里所有的 callback 风格代码改成 async/await&quot;</p>
<p><strong>AI 做的事：</strong></p>
<ul>
<li>遍历项目文件</li>
<li>逐个改造异步函数</li>
<li>保持逻辑一致的同时更新代码风格</li>
</ul>
<h3>场景 4：并行修复 Bug</h3>
<p><strong>你说：</strong> &quot;同时修复 issue #78 和 #99，分别在不同的分支上&quot;</p>
<p><img src="/images/unsplash/photo-1504384308090-c894fdcc538d-40sbgd.jpg" alt="并行开发"></p>
<p><strong>AI 做的事：</strong></p>
<ul>
<li>用 git worktree 创建两个隔离环境</li>
<li>同时启动两个 Claude Code 实例并行工作</li>
<li>各自提交修复，互不干扰</li>
</ul>
<h2>高级技巧</h2>
<h3>1. 后台长时间任务</h3>
<p>对于耗时较长的任务，AI 会自动在后台运行，你可以继续做其他事情，完成后会通知你。</p>
<h3>2. 自动完成通知</h3>
<p>对于特别长的任务，可以自动附加一个完成通知机制，确保你不会错过结果。</p>
<h3>3. 随时干预</h3>
<p>如果任务进行中需要你的确认，AI 会暂停并询问你，而不是自作主张。</p>
<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="AI 协作"></p>
<h2>使用注意事项</h2>
<p><strong>✅ 适合的场景：</strong></p>
<ul>
<li>创建新项目或新模块</li>
<li>代码审查和安全检查</li>
<li>大规模重构</li>
<li>并行修复多个 Bug</li>
<li>任何需要「自主探索 + 编码」的任务</li>
</ul>
<p><strong>❌ 不适合的场景：</strong></p>
<ul>
<li>改一行代码（直接告诉 AI 改就行，不需要启动 Claude Code）</li>
<li>读代码理解逻辑（直接让 AI 读就行）</li>
<li>简单的代码片段生成</li>
</ul>
<h2>一句话总结</h2>
<blockquote>
<p><strong>跟 AI 说人话，让 Claude Code 干活。</strong> 你负责提出需求，它负责实现、调试、提交。</p>
</blockquote>
<p><img src="/images/unsplash/photo-1517694712202-14dd9538aa97-40sbgd.jpg" alt="AI 编程未来"></p>
<p>Coding-Agent Skill 把 Claude Code 从一个「聊天工具」变成了一个「自动化编程助手」——这就是 AI 编程的正确打开方式。</p>
<p><em>本文介绍的 Coding-Agent Skill 是 OpenClaw 的内置功能。如果你想了解更多 OpenClaw 的使用技巧，欢迎持续关注。</em></p>
]]></content>
    <category term="技术专题"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Coding 阶段：多 Agent 协同开发，迭代交付高质量代码</title>
    <id>https://www.fen9pi.cn/posts/coding-phase/</id>
    <link href="https://www.fen9pi.cn/posts/coding-phase/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="Coding 阶段"></p>
<blockquote>
<p><strong>如何让多个 AI Agent 协同开发高质量代码？</strong></p>
<p><strong>Coding 阶段：多 Agent 协同开发与迭代交付</strong></p>
<p><strong>编排 Agent + 开发 Agent + 评审 Agent</strong></p>
<p><strong>编码 → 质检 → 反馈 → 修改，质量内建</strong></p>
<p><strong>来源：AI 辅助开发流程实践</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1555066931-4365d14bab8c-40sbgd.jpg" alt="Coding 阶段"></p>
<blockquote>
<p><strong>如何让多个 AI Agent 协同开发高质量代码？</strong></p>
<p><strong>Coding 阶段：多 Agent 协同开发与迭代交付</strong></p>
<p><strong>编排 Agent + 开发 Agent + 评审 Agent</strong></p>
<p><strong>编码 → 质检 → 反馈 → 修改，质量内建</strong></p>
<p><strong>来源：AI 辅助开发流程实践</strong></p>
</blockquote>
]]></content>
    <category term="方法论"/>
    <published>2026-07-20T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">认知债：比技术债更危险的组织隐疾</title>
    <id>https://www.fen9pi.cn/posts/cognitive-debt/</id>
    <link href="https://www.fen9pi.cn/posts/cognitive-debt/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1502877338535-766e1452684a-40sbgd.jpg" alt="认知负担"></p>
<blockquote>
<p>技术债让系统变慢。认知债让系统变得不可理解。</p>
</blockquote>
<p>我们都知道技术债——代码写得不够优雅，架构不够合理，迟早要重构。但有一种债务，比技术债更隐蔽、更难偿还、破坏力更强。</p>
<p>它叫<strong>认知债（Cognitive Debt）</strong>。</p>
<h2>什么是认知债？</h2>
<p>想象一个场景：</p>
<p>新来的高级工程师想改一个核心模块。他打开代码，发现逻辑是能看懂的，但越看越觉得不对——</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1502877338535-766e1452684a-40sbgd.jpg" alt="认知负担"></p>
<blockquote>
<p>技术债让系统变慢。认知债让系统变得不可理解。</p>
</blockquote>
<p>我们都知道技术债——代码写得不够优雅，架构不够合理，迟早要重构。但有一种债务，比技术债更隐蔽、更难偿还、破坏力更强。</p>
<p>它叫<strong>认知债（Cognitive Debt）</strong>。</p>
<h2>什么是认知债？</h2>
<p>想象一个场景：</p>
<p>新来的高级工程师想改一个核心模块。他打开代码，发现逻辑是能看懂的，但越看越觉得不对——</p>
<ul>
<li>为什么用这个算法，而不是更简单的方案？</li>
<li>这个配置项到底是做什么的？关了会怎样？</li>
<li>这个 if 分支是 bug 修复还是业务需求？</li>
<li>这段注释说「临时方案」，但它是三年前写的</li>
</ul>
<p>他问团队里的老人。老人说：「别动这个，当初踩过坑的。」</p>
<p>什么坑？不知道。踩坑的人走了，文档没写，代码没注释。</p>
<p><strong>这就是认知债——当「为什么这样做」的知识没有被沉淀和传递，每个后来者都要重新交学费。</strong></p>
<p><img src="/images/unsplash/photo-1504893524553-b855bce32c67-40sbgd.jpg" alt="知识断层"></p>
<h2>认知债 vs 技术债</h2>
<p>很多人会把两者混为一谈。它们确实经常同时出现，但本质不同：</p>
<p><strong>技术债</strong>是代码层面的。你知道它在哪里，知道大概怎么修，只是没时间修。</p>
<p><strong>认知债</strong>是理解层面的。你甚至不知道债在哪里，直到你需要改它的时候。</p>
<p>打个比方：</p>
<ul>
<li>技术债像是房子里的水管老化——你知道该换，虽然还没漏水</li>
<li>认知债像是你买了二手房，但没有拿到图纸——你不知道哪面墙是承重墙，哪根管子通向哪里</li>
</ul>
<p><strong>技术债可以量化，认知债不可见。</strong></p>
<p>更可怕的是：技术债可以通过重构偿还，而认知债——<strong>如果原始知识已经丢失，可能永远无法偿还。</strong></p>
<h2>认知债的五种症状</h2>
<p>你的组织有没有认知债？看看这五个问题：</p>
<h3>症状 1：「为什么这样设计？」——没人答得上来</h3>
<p>这是最经典的信号。</p>
<p>当一个决策看起来不合理，但所有人都默认它是对的，只是没人知道原因——这个决策背后的认知已经丢失了。</p>
<p>它可能是一个正确的权衡（在当时的约束下），也可能是一个错误的遗留。但当上下文消失后，它变成了一个<strong>不可置疑的神谕</strong>。</p>
<p><img src="/images/unsplash/photo-1494976388531-d1058494cdd8-40sbgd.jpg" alt="团队讨论"></p>
<h3>症状 2：哪些约束是真的约束？</h3>
<p>每个系统都有限制。但有些限制是<strong>技术层面的硬约束</strong>（比如数据库不支持某种查询），有些是<strong>历史原因的软约束</strong>（比如「当初为了赶工期用了这个方案」）。</p>
<p>硬约束需要尊重，软约束可以挑战。</p>
<p>但如果团队分不清哪些是硬约束、哪些是软约束，就会出现两种极端：</p>
<ul>
<li>把所有约束都当成硬约束，系统永远无法演进</li>
<li>忽视真正的硬约束，导致灾难性故障</li>
</ul>
<p><strong>两种情况都会让系统走向僵化或崩溃。</strong></p>
<h3>症状 3：哪些是临时方案？</h3>
<p>「先这样，后面再改。」</p>
<p>每个写过代码的人都说过这句话。但问题是——<strong>「后面」常常永远不会来。</strong></p>
<p>临时方案经过三年的「正常使用」，已经被十个新的模块依赖。它不再是临时方案，它是基础设施。</p>
<p>但没有人正式承认这件事。它的代码注释还写着「TODO: 重构」，它的技术文档还写着「暂定方案」。</p>
<p><strong>当临时方案变成事实标准，却没有人知道它是临时的——这就是认知债最典型的形态。</strong></p>
<p><img src="/images/unsplash/photo-1503376780353-7e6692767b70-40sbgd.jpg" alt="临时代码"></p>
<h3>症状 4：哪些选择不能碰？</h3>
<p>有些模块被称为「雷区」。团队里流传着一种模糊的共识：「那个东西别碰。」</p>
<p>但「不能碰」的原因，往往是某个人在某次事故中学到的经验。当这个人离开后，「不能碰」变成了一条没有注释的禁忌。</p>
<p>新的团队成员不知道为什么不能碰，只知道不能碰。于是他们绕过它，在它周围搭建越来越多的变通方案。</p>
<p><strong>系统的复杂性就这样在恐惧中增长。</strong></p>
<h3>症状 5：这些模式推荐吗？</h3>
<p>当你在代码库中看到两种完全不同的实现风格——</p>
<ul>
<li>一部分用状态机管理流程</li>
<li>另一部分用 if-else 堆砌逻辑</li>
<li>有的模块有完整的错误处理</li>
<li>有的模块直接 throw 一个字符串</li>
</ul>
<p>新来的工程师会问：「我们团队推荐哪种写法？」</p>
<p>如果团队回答不出这个问题，说明团队<strong>没有形成可传递的工程共识</strong>。每个人都在用自己的理解写代码，代码库变成了一本用多种方言写成的书。</p>
<p><img src="/images/unsplash/photo-1520869562399-e772f042f422-40sbgd.jpg" alt="代码风格"></p>
<h2>认知债是怎么积累的？</h2>
<p>认知债不是一天产生的。它在这些场景中悄悄积累：</p>
<p><strong>人员流动</strong></p>
<p>这是最大的认知债来源。每当一个有经验的工程师离开，他带走了大量的隐性知识——那些没有写进文档、只存在于他脑子里的上下文。</p>
<p><strong>会议即知识</strong></p>
<p>很多关键决策是在会议中讨论的，但会议纪要只记录了结论，没有记录推导过程。</p>
<p>三年后，有人看到这个决策，想了解原因，翻开纪要只看到「经讨论决定采用方案 B」。</p>
<p>为什么选 B？不知道。</p>
<p><strong>代码即文档</strong></p>
<p>「代码就是最好的文档」这句话有一个致命前提——<strong>读代码的人和写代码的人有相同的认知水平。</strong></p>
<p>但事实是，读代码的人往往不知道写代码的人当时面对的约束、权衡和取舍。代码只能告诉你「做了什么」，不能告诉你「为什么这样做」。</p>
<p><strong>AI 加速生产，但不传递理解</strong></p>
<p>AI 编程工具让代码产出速度翻倍，但它产出的是<strong>没有上下文的代码</strong>。</p>
<p>AI 不会告诉你「我选择用这个库是因为团队已经熟悉它」或「这里用了更啰嗦的写法是因为性能测试表明它快 15%」。</p>
<p><strong>AI 生成的每一行代码，如果没有人工审查和注释上下文，都在增加认知债。</strong></p>
<p><img src="/images/unsplash/photo-1521737711867-e3b97375f902-40sbgd.jpg" alt="AI 与代码"></p>
<h2>认知债的复利效应</h2>
<p>技术债会拖慢开发速度。认知债会让开发速度<strong>指数级下降</strong>。</p>
<p>因为认知债有复利效应：</p>
<ol>
<li>新人看不懂旧代码 → 写出更多的变通方案</li>
<li>变通方案增加了系统复杂度 → 下一个新人更难理解</li>
<li>更难理解 → 更多的「不要碰」区域</li>
<li>更多禁区 → 更多变通方案</li>
<li>循环往复</li>
</ol>
<p>最终，团队大部分时间不是在开发新功能，而是在<strong>试图理解旧代码</strong>和<strong>绕过旧代码</strong>。</p>
<p>这就是为什么有些团队明明人数不少，但产出却很低——他们不是在建系统，他们是在<strong>考古</strong>。</p>
<p><img src="/images/unsplash/photo-1560472355-536de3962603-40sbgd.jpg" alt="系统复杂度"></p>
<h2>如何偿还认知债？</h2>
<p>认知债无法通过重构代码偿还。它需要的是<strong>知识工程</strong>。</p>
<h3>1. 建立「决策记录」制度</h3>
<p>对每一个重要的技术决策，记录：</p>
<ul>
<li><strong>What</strong>：我们做了什么决定</li>
<li><strong>Why</strong>：为什么这样做（包括考虑了哪些替代方案）</li>
<li><strong>Context</strong>：当时的约束是什么</li>
<li><strong>Trade-off</strong>：我们放弃了什么</li>
<li><strong>Who</strong>：谁做的决定（方便后人追问）</li>
</ul>
<p>不需要很正式。一个 <code>DECISIONS.md</code> 文件，每条记录三五句话就够了。</p>
<p>关键是——<strong>在做决定的时候记录，而不是事后回忆。</strong></p>
<h3>2. 代码注释应该回答「为什么」</h3>
<div class="language-python line-numbers-mode" data-highlighter="shiki" data-ext="python" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code class="language-python"><span class="line"><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic"># ❌ 无用注释</span></span>
<span class="line"><span style="--shiki-light:#383A42;--shiki-dark:#ABB2BF">x </span><span style="--shiki-light:#383A42;--shiki-dark:#56B6C2">=</span><span style="--shiki-light:#383A42;--shiki-dark:#ABB2BF"> x </span><span style="--shiki-light:#383A42;--shiki-dark:#56B6C2">+</span><span style="--shiki-light:#986801;--shiki-dark:#D19A66"> 1</span><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic">  # 加1</span></span>
<span class="line"></span>
<span class="line"><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic"># ❌ 仍然无用</span></span>
<span class="line"><span style="--shiki-light:#383A42;--shiki-dark:#ABB2BF">x </span><span style="--shiki-light:#383A42;--shiki-dark:#56B6C2">=</span><span style="--shiki-light:#383A42;--shiki-dark:#ABB2BF"> x </span><span style="--shiki-light:#383A42;--shiki-dark:#56B6C2">+</span><span style="--shiki-light:#986801;--shiki-dark:#D19A66"> 1</span><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic">  # 补偿offset</span></span>
<span class="line"></span>
<span class="line"><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic"># ✅ 有用</span></span>
<span class="line"><span style="--shiki-light:#383A42;--shiki-dark:#ABB2BF">x </span><span style="--shiki-light:#383A42;--shiki-dark:#56B6C2">=</span><span style="--shiki-light:#383A42;--shiki-dark:#ABB2BF"> x </span><span style="--shiki-light:#383A42;--shiki-dark:#56B6C2">+</span><span style="--shiki-light:#986801;--shiki-dark:#D19A66"> 1</span><span style="--shiki-light:#A0A1A7;--shiki-light-font-style:italic;--shiki-dark:#7F848E;--shiki-dark-font-style:italic">  # 下标从0开始，但第三方API返回的索引从1开始</span></span></code></pre>
<div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p><strong>好的注释不是描述代码在做什么，而是解释代码为什么这样做。</strong></p>
<h3>3. 定期做「认知审计」</h3>
<p>每隔一个季度，让团队回答这五个问题：</p>
<ul>
<li>最近有新人问过哪些让你答不上来的问题？</li>
<li>有哪些模块你不敢碰？原因是什么？还有人记得最初的原因吗？</li>
<li>有哪些「临时方案」已经运行超过一年了？</li>
<li>代码库里有哪些模式是「只此一家」的？</li>
<li>如果核心成员离职，哪些知识会丢失？</li>
</ul>
<p>如果团队回答不出这些问题，认知债已经很严重了。</p>
<h3>4. 为 AI 生成的代码附加「认知注释」</h3>
<p>如果你用 AI 生成代码，在合并前多做一步：在关键位置添加人工注释，说明这段代码为什么这样写、和上下文的关系是什么。</p>
<p><strong>AI 负责生产代码，人类负责传递理解。</strong></p>
<p><img src="/images/unsplash/photo-1450101499163-c8848c66ca85-40sbgd.jpg" alt="团队协作"></p>
<h2>写在最后</h2>
<p>技术债我们可以慢慢还。但如果认知债继续积累，总有一天，系统会变成一个<strong>黑箱</strong>——它还在运行，但没有人知道它为什么运行，也没有人敢碰它。</p>
<p>到那个时候，你不是在维护系统，你是在供奉系统。</p>
<p>区别在于：维护是你理解它，供奉是你害怕它。</p>
<p><strong>从今天开始，问问你的团队：我们最老的认知债是什么？</strong></p>
<p>答案可能会让你意外。</p>
<p><em>认知债的偿还，从第一次问「为什么」开始。</em></p>
]]></content>
    <category term="方法论"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 时代的认知投降：当循环自己跑起来，你会很想停止判断</title>
    <id>https://www.fen9pi.cn/posts/cognitive-surrender/</id>
    <link href="https://www.fen9pi.cn/posts/cognitive-surrender/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="认知投降"></p>
<blockquote>
<p><strong>当循环自己跑起来，你会很想停止有自己的判断。</strong></p>
<p><strong>它给什么你就收什么。</strong></p>
<p><strong>这句话戳中的，是一种特别舒服、又特别危险的状态。</strong></p>
</blockquote>
<hr>
<h2>什么是「认知投降」？</h2>
<p><strong>验证债和理解腐烂是技术问题，认知投降是态度问题。</strong></p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="认知投降"></p>
<blockquote>
<p><strong>当循环自己跑起来，你会很想停止有自己的判断。</strong></p>
<p><strong>它给什么你就收什么。</strong></p>
<p><strong>这句话戳中的，是一种特别舒服、又特别危险的状态。</strong></p>
</blockquote>
]]></content>
    <category term="随笔"/>
    <published>2026-06-18T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Compound Engineering：让每次开发都比上一次更容易</title>
    <id>https://www.fen9pi.cn/posts/compound-engineering/</id>
    <link href="https://www.fen9pi.cn/posts/compound-engineering/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p>&quot;</p>
<h2>前言：当开发遇上&quot;复利效应&quot;</h2>
<p>想象这样一个场景：</p>
<p>你的团队正在开发一个新功能。按照传统方式：</p>
<ul>
<li>第一次实现：花了 3 天</li>
<li>第二次类似功能：花了 2.5 天（因为有经验）</li>
<li>第三次类似功能：花了 2 天（更熟练了）</li>
<li>...</li>
<li>第十次类似功能：还是花了 2 天（遇到新问题）</li>
</ul>
<p>这看起来像是&quot;熟能生巧&quot;，但实际上，你的效率并没有真正提升，因为你每次都在重复解决类似的问题。</p>]]></summary>
    <content type="html"><![CDATA[<p>&quot;</p>
<h2>前言：当开发遇上&quot;复利效应&quot;</h2>
<p>想象这样一个场景：</p>
<p>你的团队正在开发一个新功能。按照传统方式：</p>
<ul>
<li>第一次实现：花了 3 天</li>
<li>第二次类似功能：花了 2.5 天（因为有经验）</li>
<li>第三次类似功能：花了 2 天（更熟练了）</li>
<li>...</li>
<li>第十次类似功能：还是花了 2 天（遇到新问题）</li>
</ul>
<p>这看起来像是&quot;熟能生巧&quot;，但实际上，你的效率并没有真正提升，因为你每次都在重复解决类似的问题。</p>
<p>现在，想象另一种方式：</p>
<p><strong>Compound Engineering（复合工程）</strong></p>
<ul>
<li>第一次实现：花了 3 天，但记录了所有经验和模式</li>
<li>第二次类似功能：花了 1 天（复用了文档化的经验）</li>
<li>第三次类似功能：花了 0.5 天（模式已经固化）</li>
<li>...</li>
<li>第十次类似功能：花了 0.2 天（几乎自动化）</li>
</ul>
<p>这就是<strong>复利效应</strong>在软件开发中的应用。</p>
<p>今天，我们就来探索这个野心勃勃的开源项目：<strong>Compound Engineering</strong>。</p>
]]></content>
    <category term="方法论"/>
    <published>2026-07-22T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Compound Engineering：让每一次工程工作都比上一次更简单</title>
    <id>https://www.fen9pi.cn/posts/compound-engineering-knowledge/</id>
    <link href="https://www.fen9pi.cn/posts/compound-engineering-knowledge/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="Compound Engineering"></p>
<blockquote>
<p><strong>传统开发积累技术债。</strong></p>
<p><strong>每个功能增加复杂度。</strong></p>
<p><strong>每个 Bug 修复留下一小部分本地知识，需要有人重新发现。</strong></p>
<p><strong>代码库变大，上下文变难，下一次变更变慢。</strong></p>
<p><strong>Compound Engineering 反转了这个过程。</strong></p>
<p><strong>每一次工程工作都比上一次更简单。</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="Compound Engineering"></p>
<blockquote>
<p><strong>传统开发积累技术债。</strong></p>
<p><strong>每个功能增加复杂度。</strong></p>
<p><strong>每个 Bug 修复留下一小部分本地知识，需要有人重新发现。</strong></p>
<p><strong>代码库变大，上下文变难，下一次变更变慢。</strong></p>
<p><strong>Compound Engineering 反转了这个过程。</strong></p>
<p><strong>每一次工程工作都比上一次更简单。</strong></p>
</blockquote>
]]></content>
    <category term="方法论"/>
    <published>2026-06-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">孔子的教学方法：不愤不启，不悱不发</title>
    <id>https://www.fen9pi.cn/posts/confucius-teaching/</id>
    <link href="https://www.fen9pi.cn/posts/confucius-teaching/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1529390079861-591de354faf5-40sbgd.jpg" alt="孔子讲学"></p>
<blockquote>
<p>「不愤不启，不悱不发。举一隅不以三隅反，则不复也。」</p>
<p>这句话出自《论语·述而》，是孔子关于教学方法最核心的论述。</p>
<p>两千五百年后，它依然是最先进的教育理念。</p>
</blockquote>
<h2>这句话在说什么？</h2>
<p><strong>「不愤不启」</strong></p>
<p>不到学生想弄通但弄不通的时候，不要去开导他。</p>
<p><strong>「不悱不发」</strong></p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1529390079861-591de354faf5-40sbgd.jpg" alt="孔子讲学"></p>
<blockquote>
<p>「不愤不启，不悱不发。举一隅不以三隅反，则不复也。」</p>
<p>这句话出自《论语·述而》，是孔子关于教学方法最核心的论述。</p>
<p>两千五百年后，它依然是最先进的教育理念。</p>
</blockquote>
<h2>这句话在说什么？</h2>
<p><strong>「不愤不启」</strong></p>
<p>不到学生想弄通但弄不通的时候，不要去开导他。</p>
<p><strong>「不悱不发」</strong></p>
<p>不到学生想说但说不出来的时候，不要去启发他。</p>
<p><strong>「举一隅不以三隅反，则不复也」</strong></p>
<p>给他讲了一方面，他却不能推知其他方面，就不要再重复教了。</p>
]]></content>
    <category term="随笔"/>
    <published>2026-06-01T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">AI 编程第一课：模型是概率机器，别指望它两次给同一个答案</title>
    <id>https://www.fen9pi.cn/posts/cursor-learn-1/</id>
    <link href="https://www.fen9pi.cn/posts/cursor-learn-1/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>Cursor 官方出了套免费课程（Cursor Learn），教开发者怎么用 AI 写代码。不讲机器学习，不讲训练模型，就讲一件事：<strong>怎么把 AI 模型用明白</strong>。</p>
<p>这是系列第一篇，讲根基：模型到底是怎么工作的。
&quot;
原文有个开场比喻很准：把 AI 模型理解为&quot;超智能的通用 API 端点&quot;。你集成 Stripe 处理支付、用 Twilio 发短信，同样可以调用 AI 模型干各种活。</p>
<p>最大的区别只有一个：<strong>你无法保证每次得到相同的结果。</strong></p>
<p>课程地址：https://cursor.com/cn/learn</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>Cursor 官方出了套免费课程（Cursor Learn），教开发者怎么用 AI 写代码。不讲机器学习，不讲训练模型，就讲一件事：<strong>怎么把 AI 模型用明白</strong>。</p>
<p>这是系列第一篇，讲根基：模型到底是怎么工作的。
&quot;
原文有个开场比喻很准：把 AI 模型理解为&quot;超智能的通用 API 端点&quot;。你集成 Stripe 处理支付、用 Twilio 发短信，同样可以调用 AI 模型干各种活。</p>
<p>最大的区别只有一个：<strong>你无法保证每次得到相同的结果。</strong></p>
<p>课程地址：https://cursor.com/cn/learn</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-09-14T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">上下文才是 AI 编程的核心：不是提示词写得多好，而是喂对了东西</title>
    <id>https://www.fen9pi.cn/posts/cursor-learn-2/</id>
    <link href="https://www.fen9pi.cn/posts/cursor-learn-2/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>Cursor Learn 系列第二篇，讲一个多数人认知错位的点。</p>
<p>你以为提升 AI 输出质量靠写更好的提示词。有帮助，但不是关键。课程原话：<strong>与 AI 模型协作的本质在于管理你提供的上下文</strong>。</p>
<p>上下文管得好，平庸的提示词也能出好活；上下文喂错了，文采再好的提示词也救不回来。</p>
<hr>
<h2>一、这一课的身份</h2>
<p>&quot;
系列两课合一：《上下文》+《工具调用》。前者讲上下文是什么、为什么有限；后者讲模型怎么自己动手取上下文。合起来正好是&quot;上下文工程&quot;的完整拼图。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>Cursor Learn 系列第二篇，讲一个多数人认知错位的点。</p>
<p>你以为提升 AI 输出质量靠写更好的提示词。有帮助，但不是关键。课程原话：<strong>与 AI 模型协作的本质在于管理你提供的上下文</strong>。</p>
<p>上下文管得好，平庸的提示词也能出好活；上下文喂错了，文采再好的提示词也救不回来。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-09-14T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Agent 是个不知疲倦的初级开发者：委派的艺术</title>
    <id>https://www.fen9pi.cn/posts/cursor-learn-3/</id>
    <link href="https://www.fen9pi.cn/posts/cursor-learn-3/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>Cursor Learn 系列第三篇，进入正题：Agent。</p>
<p>课程里有一句定性的话，比任何技术定义都好用：<strong>把 Agent 看作行动迅速的初级开发者</strong>——需要明确指导，容易忘事，需要监督，还可能陷入循环反复用同一种失败方法。</p>
<p>这篇把 Agent 的原理和协作方法一次讲清，素材来自课程《Agents》和《与智能体协作》两课。</p>
<hr>
<h2>一、这一课的身份</h2>
<ul>
<li><strong>谁写的</strong>：Cursor 官方课程</li>
<li><strong>讲什么</strong>：Agent 是什么（工具+循环）、怎么委派任务、怎么写提示词、怎么管上下文、怎么避开失败模式</li>
<li><strong>核心立场</strong>：目标不是消除人工参与，而是放大你能完成的工作——<strong>你成为架构师和审阅人，Agent 负责实现细节</strong></li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>Cursor Learn 系列第三篇，进入正题：Agent。</p>
<p>课程里有一句定性的话，比任何技术定义都好用：<strong>把 Agent 看作行动迅速的初级开发者</strong>——需要明确指导，容易忘事，需要监督，还可能陷入循环反复用同一种失败方法。</p>
<p>这篇把 Agent 的原理和协作方法一次讲清，素材来自课程《Agents》和《与智能体协作》两课。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-09-14T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">用 Cursor 一个月才懂的三件事</title>
    <id>https://www.fen9pi.cn/posts/cursor-three-lessons-v2/</id>
    <link href="https://www.fen9pi.cn/posts/cursor-three-lessons-v2/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[
<p>用 AI 写代码的人分两种：一种以为提示词是关键，一种以为换个更强的模型是关键。Cursor 官方出了套免费课程（Cursor Learn），不讲机器学习不讲训练，就讲怎么把模型用明白——三课看下来，我确认自己踩过的三个误区，大概率你也在踩。</p>
<h2>误区一：以为它会给你相同的答案</h2>
<p>模型是<strong>概率机器</strong>，不是确定性 API。课程给的定义很准：把 AI 模型当作&quot;超智能的通用 API 端点&quot;——你集成 Stripe 处理支付，同样可以调用模型干活，唯一的本质区别是：<strong>你无法保证每次得到相同的结果</strong>。</p>]]></summary>
    <content type="html"><![CDATA[
<p>用 AI 写代码的人分两种：一种以为提示词是关键，一种以为换个更强的模型是关键。Cursor 官方出了套免费课程（Cursor Learn），不讲机器学习不讲训练，就讲怎么把模型用明白——三课看下来，我确认自己踩过的三个误区，大概率你也在踩。</p>
<h2>误区一：以为它会给你相同的答案</h2>
<p>模型是<strong>概率机器</strong>，不是确定性 API。课程给的定义很准：把 AI 模型当作&quot;超智能的通用 API 端点&quot;——你集成 Stripe 处理支付，同样可以调用模型干活，唯一的本质区别是：<strong>你无法保证每次得到相同的结果</strong>。</p>
<p>同样的输入，它可能走很多条不同的路。由此推出两条铁律：相同的模型和提示，可能给出不同回答；模型不总是遵循你的指令——包括&quot;只改这一个函数&quot;这种简单约束。</p>
<p>你让它只改一个函数，它顺手重构了半个文件。不是它调皮，是概率机器天然如此。与 AI 协作的第一课：<strong>验证它的输出，永远别默认它对。</strong>依赖 AI 输出的流程，测试和评审环节省不得。</p>
<p>选模型的三维框架也朴素得残忍：智能、速度、成本——又快又便宜又聪明的不存在。改错别字用旗舰模型是烧钱，让便宜模型设计架构是自虐。</p>
<h2>误区二：以为关键在提示词</h2>
<p>第二课的核心结论，认知错位重灾区：<strong>与模型协作的本质不是写更好的提示词，而是管理你提供的上下文。</strong></p>
<p>做菜比喻：食材（输入）决定汤的下限，食谱（计划）只是路径。上下文管得好，平庸的提示词也能出好活；上下文喂错了，文采再好也救不回来。</p>
<p>上下文里有两块容易被忽略的暗区：<strong>系统提示</strong>排在最前面，是工具注入的规则，你看不见但它每轮都在生效——理解这点就明白为什么同一个模型在不同工具里表现不同；<strong>自动注入</strong>是编辑器的价值所在——打开的文件、终端输出、Linter 报错都已经在场，不用手动贴。</p>
<p>还有物理极限：上下文随轮次增长，触顶后早期约定被压缩挤出，模型开始&quot;违反前面说好的事&quot;。这不是 bug，是工作记忆的容量。<strong>该新开对话时新开，别恋战</strong>——切换任务时、Agent 开始反复犯错时，都是明确的信号。</p>
<p>工具调用和 MCP 是这课的延伸：模型能自己取上下文（读文件、跑命令、搜代码），MCP 让工具构建一次处处运行——<strong>模型的能力边界，由你接了什么工具定义</strong>。</p>
<h2>误区三：以为 Agent 靠谱</h2>
<p>第三课有句定性，比任何技术定义都好用：<strong>把 Agent 看作行动迅速的初级开发者——需要明确指导，容易忘事，需要监督，还可能陷入循环反复用同一种失败方法。</strong></p>
<p>委派的艺术核心是一条：<strong>Agent 会遵循你的现有模式，而不是自行创造新模式——前提是你把模式指给它看。</strong>对比一下就懂：</p>
<p>模糊版：&quot;添加用户设置页面。&quot;——它得猜布局、猜组件、猜样式，有时能蒙对，通常不能。</p>
<p>明确版：&quot;添加用户设置页面。查看 <code>src/app/profile/page.tsx</code> 里现有的配置页，参考我们的布局模式；用 <code>src/components/ui/Form.tsx</code> 的表单组件；设置项：显示名称（文本）、邮件通知（开关）、主题（下拉）；用现有的 <code>useUserPreferences</code> hook。&quot;——引用现有文件、现有组件、清晰范围。</p>
<p>最常见的失败模式排第一的是<strong>范围失控</strong>：没做好规划就要大范围更改——Agent 做了无关改动、动了你不想动的文件。处方是把任务拆小、把边界写进提示词，而不是事后收拾。</p>
<p>最后一句课程原话值得裱起来：委派的是实现，不是责任。<strong>验证代码能否运行、是否符合你的标准，永远是你的事。</strong></p>
<p><strong>聊两句</strong>：三个误区你踩过哪个最狠？我投&quot;恋战不换对话&quot;一票——曾经在一个 40 万 token 的会话里反复纠偏，新开对话五分钟就解决了。评论区说说你的案例，我置顶我的完整踩坑清单。</p>
<p>往期：LVS、双模型流水线、扫描 PDF 转 EPUB 都在主页；下一篇把整个 GitHub 搬进终端。关注不迷路。</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-10-09T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Cynefin 框架告诉你：哪些岗位会被 AI 替代，哪些不会</title>
    <id>https://www.fen9pi.cn/posts/cynefin-ai-jobs/</id>
    <link href="https://www.fen9pi.cn/posts/cynefin-ai-jobs/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="Cynefin 框架"></p>
<blockquote>
<p><strong>Cynefin 框架是一个决策工具。</strong></p>
<p>它把问题分成五个域：简单、繁杂、复杂、混沌、无序。</p>
<p>但今天我们要用它来回答一个更现实的问题：<strong>在 AI 时代，哪些岗位会被替代，哪些不会？</strong></p>
<p>答案不在于「这个岗位是做什么的」，而在于「这个岗位处理的是哪种类型的问题」。</p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1516116216624-53e697fedbea-40sbgd.jpg" alt="Cynefin 框架"></p>
<blockquote>
<p><strong>Cynefin 框架是一个决策工具。</strong></p>
<p>它把问题分成五个域：简单、繁杂、复杂、混沌、无序。</p>
<p>但今天我们要用它来回答一个更现实的问题：<strong>在 AI 时代，哪些岗位会被替代，哪些不会？</strong></p>
<p>答案不在于「这个岗位是做什么的」，而在于「这个岗位处理的是哪种类型的问题」。</p>
</blockquote>
<h2>Cynefin 框架的五个域</h2>
<p><img src="/images/unsplash/photo-1551288049-bebda4e38f71-40sbgd.jpg" alt="五个域"></p>
<p>Cynefin 框架把问题分成五类：</p>
<p>| 域 | 特征 | 例子 |
|</p>
]]></content>
    <category term="AI 工程"/>
    <published>2026-06-02T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">我们正在进入的危险状态：没人真正理解的系统</title>
    <id>https://www.fen9pi.cn/posts/dangerous-state/</id>
    <link href="https://www.fen9pi.cn/posts/dangerous-state/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1579532537598-459ecdaf39cc-40sbgd.jpg" alt="无人理解的系统">
&quot;</p>
<blockquote>
<p>&quot;一个没人真正理解，但大家都还能继续往上写代码的系统。&quot;</p>
</blockquote>
<p>这句话来自一位硅谷资深工程师的深夜推文。它精准地描述了一个正在蔓延的现象——我们正在构建的东西，已经没有人能完整地理解了。</p>
<p>而最危险的是：<strong>它还在正常运转。</strong></p>
<h2>一个真实的故事</h2>
]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1579532537598-459ecdaf39cc-40sbgd.jpg" alt="无人理解的系统">
&quot;</p>
<blockquote>
<p>&quot;一个没人真正理解，但大家都还能继续往上写代码的系统。&quot;</p>
</blockquote>
<p>这句话来自一位硅谷资深工程师的深夜推文。它精准地描述了一个正在蔓延的现象——我们正在构建的东西，已经没有人能完整地理解了。</p>
<p>而最危险的是：<strong>它还在正常运转。</strong></p>
<h2>一个真实的故事</h2>
<p>2024年，某大型互联网公司的支付系统出了一次事故。</p>
<p>排查过程中，团队发现一个核心模块已经运行了7年。最初写它的工程师早已离职，文档是3年前更新的，测试覆盖率不到30%。没人敢动它，因为它「一直好好的」。</p>
<p>这次故障的原因：一个时间戳格式的微妙变化，在不同的时区条件下触发了边界异常。</p>
<p>团队花了3天才定位到问题。</p>
<p>这3天里，他们反复说的一句话是：<strong>「这段代码到底在干什么？」</strong></p>
<p><img src="/images/unsplash/photo-1556761175-4b46a572b786-40sbgd.jpg" alt="代码迷宫"></p>
<h2>抽象的诅咒</h2>
<p>现代软件开发的本质是一层层抽象。</p>
<ul>
<li>你用 React 写前端，不需要理解 Virtual DOM 的 diff 算法</li>
<li>你用 Kubernetes 部署服务，不需要理解容器的 cgroup 和 namespace</li>
<li>你调一个 REST API，不需要知道底层走的是 TCP 还是 QUIC</li>
<li>你用 AI 生成代码，不需要理解 Transformer 的注意力机制</li>
</ul>
<p><strong>抽象是进步的标志。</strong> 每一层抽象都让更多人能参与建设，让复杂系统变得可用。</p>
<p>但抽象也是一个诅咒——<strong>它让我们习惯了「不理解也能工作」。</strong></p>
<p>当每一层都只需要理解上一层的接口时，整个系统就变成了一个巨大的黑箱。每个人都在自己的层里忙碌，但没有任何人能看到全貌。</p>
<p><img src="/images/unsplash/photo-1600880292203-757bb62b4baf-40sbgd.jpg" alt="抽象层级"></p>
<h2>AI 让这个趋势加速了</h2>
<p>现在，AI 编程工具正在把这个问题推到一个新高度。</p>
<p>以前，你至少需要读懂代码才能修改它。现在，你可以让 AI 直接生成补丁，提交 PR，通过 CI，合并部署——<strong>全程不需要真正理解这段代码的含义。</strong></p>
<p>这不是科幻。这正在发生。</p>
<p>AI 生成的代码往往能通过测试、能跑起来、能解决问题。但它也常常包含一些微妙的「不合理」——没有被测试覆盖的边界情况、与业务语义不一致的命名、看似正确但逻辑上冗余的分支。</p>
<p>这些东西不会在第一天暴露。它们会像定时炸弹一样，埋在代码库的深处。</p>
<p><strong>等到下一个工程师（或者下一个 AI）来修改这段代码时，没人知道哪些是刻意的设计，哪些是随机的产物。</strong></p>
<p><img src="/images/unsplash/photo-1553877522-43269d4ea984-40sbgd.jpg" alt="AI 编程"></p>
<h2>最可怕的不是崩溃</h2>
<p>你可能会说：「代码能跑就行啊，管它理不理解？」</p>
<p>问题是——<strong>系统不只是代码。</strong></p>
<p>系统是代码、是配置、是环境变量、是第三方依赖、是运维人员的肌肉记忆、是团队成员脑子里的隐性知识。</p>
<p>当这些东西散落在各处，没有人能把它们串起来时，系统就进入了一种<strong>「薛定谔的稳定」</strong>状态：</p>
<ul>
<li>它看起来是稳定的</li>
<li>没人知道它为什么稳定</li>
<li>任何改动都可能让它不稳定</li>
<li>一旦不稳定，没人知道怎么修</li>
</ul>
<p>这不是崩溃，这是<strong>脆弱</strong>。一个脆弱的系统和一个健康的系统的区别，不在于它是否在运行，而在于——<strong>如果出了问题，需要多久才能恢复？</strong></p>
<p><img src="/images/unsplash/photo-1507679799987-c73779587ccf-40sbgd.jpg" alt="系统脆弱性"></p>
<h2>三种危险信号</h2>
<p>你的系统可能已经进入这个危险状态了吗？看看有没有这些信号：</p>
<p><strong>信号 1：「不要动那个模块」</strong></p>
<p>如果团队里有任何一个模块被标记为「不要碰」或「谁写的谁来改」——恭喜，你已经有了一个无人理解的子系统。</p>
<p><strong>信号 2：AI 生成的代码直接进入生产环境</strong></p>
<p>如果团队的流程允许 AI 生成的代码在没有深度人工审查的情况下直接合并部署——你的代码库正在快速积累不可控的复杂性。</p>
<p><strong>信号 3：新人无法在三个月内独立修复核心模块的 bug</strong></p>
<p>如果一个有经验的工程师加入团队后，需要超过三个月才能独立修复核心模块的问题——说明系统的认知负担已经超出了人类的承载能力。</p>
<p><img src="/images/unsplash/photo-1486406146926-c627a92ad1ab-40sbgd.jpg" alt="团队协作"></p>
<h2>我们能做什么？</h2>
<p>这不是一篇悲观的文章。这是一个预警。</p>
<p>我们正在构建的东西，规模和速度都超过了以往任何时代。但我们也需要正视一个事实：<strong>人类的理解能力是有上限的。</strong></p>
<p>这里有几件事，值得每个团队现在就开始做：</p>
<p><strong>1. 强制知识轮转</strong></p>
<p>不要让任何模块只有一个人理解。建立「结对维护」制度——每个核心模块至少有两个人能读懂并修改它。</p>
<p><strong>2. 把「为什么」写进代码注释</strong></p>
<p>代码告诉你「做什么」，注释应该告诉你「为什么」。特别是那些看起来奇怪的决策——为什么用这个算法？为什么不用更简单的方案？这些上下文比代码本身更珍贵。</p>
<p><strong>3. 定期进行「理解度测试」</strong></p>
<p>每隔一段时间，随机选一个核心模块，让团队里不熟悉它的人尝试解释它的逻辑。如果解释不清楚，说明这块代码需要更好的文档和更清晰的结构。</p>
<p><strong>4. 对 AI 生成的代码设置更高的审查标准</strong></p>
<p>AI 生成的代码应该接受比人类代码更严格的审查，而不是更宽松的。因为 AI 不会为自己写的代码负责，但你会。</p>
<p><strong>5. 保留「从头重建」的能力</strong></p>
<p>最危险的状态是：系统太复杂以至于无法从头重建。定期评估：如果需要，我们能用现有团队在6个月内重建核心系统吗？如果不能，你的系统已经过于脆弱了。</p>
<p><img src="/images/unsplash/photo-1542744094-3a31f272c490-40sbgd.jpg" alt="构建未来"></p>
<h2>写在最后</h2>
<p>软件工程正在经历一场深刻的变革。AI 让我们能以前所未有的速度构建系统，但也正在以前所未有的速度制造我们无法理解的复杂性。</p>
<p>这不是 AI 的错，也不是任何个人的错。这是我们整个行业在追求效率的过程中，不经意间付出的代价。</p>
<p><strong>但我们可以选择现在开始重视这件事。</strong></p>
<p>在你的下一个项目里，试试看：不只是让代码跑起来，而是让团队里的每个人都能理解它为什么跑起来。</p>
<p>因为在软件的世界里，<strong>你不能维护你不理解的东西。</strong> 而每一个不被理解的系统，最终都会变成一个定时炸弹。</p>
<p>只是没人知道它什么时候会响。</p>
<p><em>如果你觉得这篇文章有启发，欢迎转发给你身边正在「往上写代码」的朋友们。</em></p>
]]></content>
    <category term="方法论"/>
    <published>2026-05-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">道·Skill：从混沌需求生成 Agent Skill</title>
    <id>https://www.fen9pi.cn/posts/dao-skill/</id>
    <link href="https://www.fen9pi.cn/posts/dao-skill/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：道生万物</h2>
<p>道生一，一生二，二生三，三生万物。</p>
<p>一个根问题，可以生出一套稳定工作流，也可以生出一个完整 Skill 家族。</p>
<p>道·Skill 是一个 Skill 元设计器。</p>
<hr>
<h2>一、核心工作流</h2>
<p></p>
<p><strong>七步流程</strong>：</p>
<ol>
<li>混沌需求</li>
<li>道：理解真实关切</li>
<li>一：归结根问题</li>
<li>二：识别核心张力</li>
<li>三：建立天/地/人结构</li>
<li>器：选择生产模式</li>
<li>万物：生成可运行产物</li>
<li>验证 → 反馈 → 返观进化</li>
</ol>]]></summary>
    <content type="html"><![CDATA[<h2>前言：道生万物</h2>
<p>道生一，一生二，二生三，三生万物。</p>
<p>一个根问题，可以生出一套稳定工作流，也可以生出一个完整 Skill 家族。</p>
<p>道·Skill 是一个 Skill 元设计器。</p>
]]></content>
    <category term="随笔"/>
    <published>2026-08-27T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">去 AI 味的拼贴技巧：三个 Skill 一起跑</title>
    <id>https://www.fen9pi.cn/posts/de-ai-flavor-skills/</id>
    <link href="https://www.fen9pi.cn/posts/de-ai-flavor-skills/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：去 AI 味这件事，没有万能药</h2>
<p><strong>2026-08-12 16:38 GMT+8</strong>
&quot;
AI 写的东西，总有一股子&quot;AI 味&quot;。</p>
<p>结构太整齐，用词太标准，语气太平衡。</p>
<p>读起来像说明书，不像人写的。</p>
<p><strong>市面上各种去 AI 味的工具</strong>：</p>
<ul>
<li>有的靠改写</li>
<li>有的靠加错字</li>
<li>有的靠降低可读性</li>
</ul>
<p>但都没有解决根本问题：<strong>AI 的结构感太强</strong>。</p>]]></summary>
    <content type="html"><![CDATA[<h2>前言：去 AI 味这件事，没有万能药</h2>
<p><strong>2026-08-12 16:38 GMT+8</strong>
&quot;
AI 写的东西，总有一股子&quot;AI 味&quot;。</p>
<p>结构太整齐，用词太标准，语气太平衡。</p>
<p>读起来像说明书，不像人写的。</p>
<p><strong>市面上各种去 AI 味的工具</strong>：</p>
<ul>
<li>有的靠改写</li>
<li>有的靠加错字</li>
<li>有的靠降低可读性</li>
</ul>
<p>但都没有解决根本问题：<strong>AI 的结构感太强</strong>。</p>
<p><strong>最近发现了一个方法</strong>：</p>
<blockquote>
<p><strong>三个 Skill，各跑一版，拼贴起来</strong></p>
</blockquote>
]]></content>
    <category term="Skill 工程"/>
    <published>2026-08-12T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">DeepSeek Harness：Agent = Model + Harness</title>
    <id>https://www.fen9pi.cn/posts/deepseek-harness/</id>
    <link href="https://www.fen9pi.cn/posts/deepseek-harness/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：DeepSeek 的 Agent 野心</h2>
<p><strong>2026-08-14 08:40 GMT+8</strong></p>
<p><strong>AI Agent 的困境</strong>：</p>
<ul>
<li>有了强大的模型，但如何构建实用的 Agent？</li>
<li>如何接入文件系统、终端、网页？</li>
<li>如何组织上下文、工具调用和任务执行？</li>
<li>如何从原型到生产？</li>
</ul>
<p><strong>DeepSeek 的答案</strong>：</p>
<blockquote>
<p><strong>Model + Harness = Agent</strong></p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<h2>前言：DeepSeek 的 Agent 野心</h2>
<p><strong>2026-08-14 08:40 GMT+8</strong></p>
<p><strong>AI Agent 的困境</strong>：</p>
<ul>
<li>有了强大的模型，但如何构建实用的 Agent？</li>
<li>如何接入文件系统、终端、网页？</li>
<li>如何组织上下文、工具调用和任务执行？</li>
<li>如何从原型到生产？</li>
</ul>
<p><strong>DeepSeek 的答案</strong>：</p>
<blockquote>
<p><strong>Model + Harness = Agent</strong></p>
</blockquote>
<p><strong>今天介绍 DeepSeek Harness</strong>——由 DeepSeek 自己开发的 Agent Harness，负责把模型接入文件系统、终端、网页、代码工具和其他 Agent，并组织上下文、工具调用和任务执行的一整套 Agent 运行框架。</p>
]]></content>
    <category term="AI Agent"/>
    <published>2026-08-14T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">DeepTutor：终身个性化导师的开源实践</title>
    <id>https://www.fen9pi.cn/posts/deeptutor/</id>
    <link href="https://www.fen9pi.cn/posts/deeptutor/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言：个性化学习的新范式</h2>
<p>教育的终极目标是什么？</p>
<p>不是让所有人学同样的东西，而是让每个人以最适合自己的方式学习。</p>
<p>传统教育的问题是：</p>
<ul>
<li>老师无法同时关注每个学生</li>
<li>学习进度无法个性化</li>
<li>知识传授无法因材施教</li>
</ul>
<p>AI 时代的解决方案是：</p>
<ul>
<li>个性化导师（Personal Tutor）</li>
<li>自适应学习（Adaptive Learning）</li>
<li>终身学习伴侣（Lifelong Companion）</li>
</ul>]]></summary>
    <content type="html"><![CDATA[<h2>前言：个性化学习的新范式</h2>
<p>教育的终极目标是什么？</p>
<p>不是让所有人学同样的东西，而是让每个人以最适合自己的方式学习。</p>
<p>传统教育的问题是：</p>
<ul>
<li>老师无法同时关注每个学生</li>
<li>学习进度无法个性化</li>
<li>知识传授无法因材施教</li>
</ul>
<p>AI 时代的解决方案是：</p>
<ul>
<li>个性化导师（Personal Tutor）</li>
<li>自适应学习（Adaptive Learning）</li>
<li>终身学习伴侣（Lifelong Companion）</li>
</ul>
<p>今天介绍一个革命性的开源项目——<strong>DeepTutor</strong>，一个构建终身个性化导师系统的完整平台。</p>
]]></content>
    <category term="开源拆解"/>
    <published>2026-08-11T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Google 的设计文档文化：写文档不是目的，把权衡想清楚才是</title>
    <id>https://www.fen9pi.cn/posts/design-docs-google/</id>
    <link href="https://www.fen9pi.cn/posts/design-docs-google/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<h2>前言</h2>
<p>Malte Ubl（Google 资深工程总监，现 JavaScript 基础设施负责人）七年前写过一篇《Design Docs at Google》，讲 Google 内部的设计文档文化。这篇是老经典，Gergely Orosz（Uber）转发过，Uber 的 RFC/ERD 制度也和它同源。
&quot;
为什么现在还值得读？因为 AI 编程时代写代码越来越便宜，但&quot;决定写什么代码&quot;这件事没有变便宜——<strong>设计文档的核心恰恰是记录你为什么这么决定。</strong></p>
<p>文章里有句话值得先放在这：</p>
<blockquote>
<p>软件工程师的工作不是生产代码，而是解决问题。在项目早期，非结构化文本可能比代码更好的工具——更简洁、更易理解、在更高的层面沟通问题和方案。</p>
</blockquote>]]></summary>
    <content type="html"><![CDATA[<h2>前言</h2>
<p>Malte Ubl（Google 资深工程总监，现 JavaScript 基础设施负责人）七年前写过一篇《Design Docs at Google》，讲 Google 内部的设计文档文化。这篇是老经典，Gergely Orosz（Uber）转发过，Uber 的 RFC/ERD 制度也和它同源。
&quot;
为什么现在还值得读？因为 AI 编程时代写代码越来越便宜，但&quot;决定写什么代码&quot;这件事没有变便宜——<strong>设计文档的核心恰恰是记录你为什么这么决定。</strong></p>
<p>文章里有句话值得先放在这：</p>
<blockquote>
<p>软件工程师的工作不是生产代码，而是解决问题。在项目早期，非结构化文本可能比代码更好的工具——更简洁、更易理解、在更高的层面沟通问题和方案。</p>
</blockquote>
<ul>
<li>原文：https://www.industrialempathy.com/posts/design-docs-at-google/</li>
</ul>
]]></content>
    <category term="方法论"/>
    <published>2026-09-16T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">谁怕？一蓑烟雨任平生</title>
    <id>https://www.fen9pi.cn/posts/ding-feng-bo/</id>
    <link href="https://www.fen9pi.cn/posts/ding-feng-bo/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1519681393784-d120267933ba-40sbgd.jpg" alt="烟雨"></p>
<blockquote>
<p>人生最美的境界，不是在风平浪静时从容。而是在风雨交加时，依然能吟啸徐行。</p>
</blockquote>
<p>苏轼的《定风波》，写于他人生最落魄的时刻。</p>
<p>公元 1082 年，苏轼被贬黄州已经三年。从朝廷重臣到流放犯人，从春风得意到前途渺茫。</p>
<p>他和朋友出门，中途遇到大雨。朋友们狼狈奔跑，苏轼却不以为意。</p>
<p>他写下这首词，开篇两句，就是千古名句：</p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1519681393784-d120267933ba-40sbgd.jpg" alt="烟雨"></p>
<blockquote>
<p>人生最美的境界，不是在风平浪静时从容。而是在风雨交加时，依然能吟啸徐行。</p>
</blockquote>
<p>苏轼的《定风波》，写于他人生最落魄的时刻。</p>
<p>公元 1082 年，苏轼被贬黄州已经三年。从朝廷重臣到流放犯人，从春风得意到前途渺茫。</p>
<p>他和朋友出门，中途遇到大雨。朋友们狼狈奔跑，苏轼却不以为意。</p>
<p>他写下这首词，开篇两句，就是千古名句：</p>
<p><strong>「莫听穿林打叶声，何妨吟啸且徐行。」</strong></p>
<h2>莫听穿林打叶声</h2>
<p>雨打在竹林上，声音很大。人在林中，本能的反应是什么？是听雨声、是担心淋湿、是焦虑不安。</p>
<p>但苏轼说：<strong>莫听。</strong></p>
<p>不是不听。是不要让这些声音占据你的全部注意力。</p>
<p><strong>这是「选择性注意」的能力。</strong></p>
<p>现代生活中，我们每天都在「听雨声」：</p>
<ul>
<li>听老板的责骂</li>
<li>听同行的竞争</li>
<li>听社交媒体的焦虑</li>
<li>听别人的评价</li>
</ul>
<p>这些声音像雨打竹林一样，嘈杂、持续、让人不安。</p>
<p><strong>但你必须学会「莫听」。</strong></p>
<p>不是真的不听。而是不要让这些声音定义你。不要让外界的噪音，淹没了你内心的声音。</p>
<p>莫听，是一种<strong>屏蔽力</strong>。你能屏蔽那些不重要、不健康、不建设性的声音，才能听见真正重要的东西。</p>
<p><img src="/images/unsplash/photo-1519681393784-d120267933ba-40sbgd.jpg" alt="雨声"></p>
<h2>何妨吟啸且徐行</h2>
<p>雨很大，怎么办？</p>
<p>苏轼的选择是：<strong>一边哼着歌，一边慢慢走。</strong></p>
<p>「吟啸」不是大声抗议，是自得其乐。不是对雨发怒，是和雨共存。</p>
<p>「徐行」不是慌乱奔跑，是保持自己的节奏。不是让外界的环境打乱你的步调，是你在任何环境下都按自己的速度前进。</p>
<p>这两句词里，藏着苏轼的人生智慧：</p>
<p><strong>第一，不要对抗不可控的东西。</strong></p>
<p>雨会下多久，你控制不了。路会不会滑，你控制不了。有没有地方躲雨，你控制不了。</p>
<p>你能控制的，只有你的态度——你是选择焦虑，还是选择从容。</p>
<p><strong>第二，不要放弃可控的东西。</strong></p>
<p>雨很大，但你依然可以哼歌。路很滑，但你依然可以选择慢慢走。环境很差，但你依然可以保持内心的秩序。</p>
<p><strong>这就是「徐行」的力量——在外界的混乱中，保持内心的节奏。</strong></p>
<h2>竹杖芒鞋轻胜马</h2>
<p>苏轼的装备很差：竹杖、草鞋。比起骑马，寒酸太多了。</p>
<p>但他却说：<strong>「轻胜马」</strong>。</p>
<p>为什么？</p>
<p>因为骑马的人，被马的速度、马的脾气、马的需求控制。骑马的人，必须配合马的节奏。</p>
<p>而拄着竹杖、穿着草鞋的人，是完全自由的。他想走多快就走多快，想停就停，想转弯就转弯。</p>
<p><strong>马代表外在的力量和资源。竹杖芒鞋代表内在的自主和简约。</strong></p>
<p>现代生活中，我们都在追求「马」——更高的职位、更多的资源、更强的工具。</p>
<p>但我们忘了：<strong>外在的资源越多，你的自由可能越少。</strong></p>
<p>职位高，你要应付更多的人际关系。资源多，你要管理更复杂的利益。工具强，你要适应工具的逻辑。</p>
<p><strong>当你拥有的东西控制了你，这些拥有就变成了束缚。</strong></p>
<p>竹杖芒鞋看似简陋，但它们属于你。你不会被它们控制，你完全掌握着主动权。</p>
<p><strong>「轻胜马」不是自我安慰，是对自由的理解。</strong></p>
<h2>谁怕？</h2>
<p>两个字，铿锵有力。</p>
<p>苏轼在问谁？在问那些害怕风雨的人。在问那些因为外界变化而焦虑的人。在问那些把安全感建立在稳定之上的人。</p>
<p><strong>「谁怕」的潜台词是：我不怕。</strong></p>
<p>为什么不怕？</p>
<p>因为苏轼已经经历过最坏的情况。他从朝廷重臣被贬为流放犯人，从杭州的黄州到黄州的贬地，从繁华都市到荒凉之地。</p>
<p><strong>他已经见过人生的低谷。</strong> 他知道再坏也坏不过去了。所以剩下的每一步，都是向上。</p>
<p><strong>真正的勇气，不是相信「一切都会好起来」。是接受了「一切可能不会好起来，但我依然能走下去」。</strong></p>
<p><img src="https://images.unsplash.com/photo-1500320821405-6d6d79614a3f?w=677&amp;h=380&amp;fit=crop" alt="谁怕"></p>
<h2>一蓑烟雨任平生</h2>
<p>最后这句，是整首词的灵魂。</p>
<p><strong>「一蓑烟雨」</strong> —— 披着蓑衣，在烟雨中行走。</p>
<p><strong>「任平生」</strong> —— 任凭平生风雨，我自前行。</p>
<p>「任」字最关键。不是「抗」，不是「躲」，是「任」。</p>
<p>你让雨下，我走我的路。风越大，我越稳。雨越大，我越从容。</p>
<p><strong>这是苏轼的人生境界：</strong></p>
<p>他不追求风平浪静的生活。他追求的是在风雨中依然能做自己。</p>
<p>他不期待世界对他温柔。他接受世界可能对他残酷，但他依然选择温柔地对待这个世界。</p>
<p>他不依赖外在的稳定。他的稳定来自内心——无论外界如何变化，他的内心秩序不变。</p>
<h2>苏轼的「反脆弱」</h2>
<p>现代术语里，苏轼的这种状态叫「反脆弱」。</p>
<p>脆弱的东西，在压力下会崩溃。比如玻璃。</p>
<p>强韧的东西，在压力下不崩溃。比如石头。</p>
<p>反脆弱的东西，在压力下会变得更强。比如肌肉——你给它压力，它会适应、会成长。</p>
<p><strong>苏轼是典型的反脆弱人格。</strong></p>
<p>如果没有被贬黄州，苏轼只是一个优秀的官员。但正是在黄州，他写下了《赤壁赋》、《念奴娇·赤壁怀古》、《定风波》。</p>
<p>如果没有经历人生的风雨，苏轼只是「苏轼」。但经历风雨后，苏轼成了「东坡」。</p>
<p><strong>他没有被风雨打倒。他利用风雨，完成了蜕变。</strong></p>
<p><img src="/images/unsplash/photo-1469474968028-56623f02e42e-40sbgd.jpg" alt="反脆弱"></p>
<h2>现代生活中的「烟雨任平生」</h2>
<p>我们可能不会经历苏轼那样的政治贬谪，但我们每个人都有自己的「风雨」：</p>
<p><strong>职场上的风雨：</strong> 被裁员、被边缘化、被误解、被攻击。</p>
<p><strong>生活中的风雨：</strong> 生病、失去亲人、经济困难、关系破裂。</p>
<p><strong>内心中的风雨：</strong> 自我怀疑、焦虑抑郁、迷茫困惑、价值危机。</p>
<p>面对这些风雨，我们能学到什么？</p>
<h3>学会一：莫听</h3>
<p>不要让所有的声音都进入你的耳朵。</p>
<p>社交媒体的噪音、同行的攀比、别人的期待——这些「雨声」不是你生命的主角。</p>
<p>你可以听，但不要让它们占据你的全部注意力。你要保留一部分注意力，给真正重要的东西——你的健康、你的家人、你的内心平静。</p>
<h3>学会二：徐行</h3>
<p>不要因为外界的变化而打乱自己的节奏。</p>
<p>环境好的时候，按你的节奏走。环境差的时候，还是按你的节奏走。</p>
<p><strong>你的节奏，是你最核心的资产。</strong></p>
<p>很多人在顺境时失序，在逆境时慌乱。他们从来没有真正建立过自己的节奏——他们的节奏是被外界控制的。</p>
<p><strong>「徐行」不是慢走。是按自己的速度走。</strong></p>
<h3>学会三：轻装</h3>
<p>不要让拥有物控制你。</p>
<p>职位、资源、工具——这些「马」能帮你，但也能困住你。</p>
<p>你要定期审视：我拥有的东西，是在服务我，还是在控制我？</p>
<p>如果是后者，该放弃就要放弃。<strong>宁可竹杖芒鞋，不要被马所困。</strong></p>
<h3>学会四：任平生</h3>
<p>不要期待世界对你温柔。但你可以选择温柔地对待这个世界。</p>
<p>「任」不是消极的接受。是积极的选择——无论外界如何变化，我都保持自己的内心秩序。</p>
<p><strong>这种内心秩序，是你给自己最好的礼物。</strong></p>
<h2>写在最后</h2>
<p>《定风波》的最后，苏轼写道：</p>
<p><strong>「回首向来萧瑟处，归去，也无风雨也无晴。」</strong></p>
<p>回头看刚才经历的风雨，已经无所谓风雨，也无所谓晴天。</p>
<p><strong>这是最终的境界：不是没有经历风雨，而是风雨已经不能定义你了。</strong></p>
<p>你现在经历的困难、挫折、痛苦——终有一天，当你回头看时，它们会变成「萧瑟处」。不是伤口，是风景。</p>
<p><strong>「一蓑烟雨任平生」不是一种消极的忍受。是一种积极的选择——选择在风雨中依然做自己。</strong></p>
<p><em>穿林打叶声，是外界的声音。吟啸徐行，是你的声音。</em></p>
<p><em>竹杖芒鞋，是你的选择。一蓑烟雨，是你的人生。</em></p>
<p><strong>谁怕？你不怕。</strong></p>
<p>&quot;</p>
]]></content>
    <category term="随笔"/>
    <published>2026-05-29T00:00:00.000Z</published>
  </entry>
  <entry>
    <title type="text">Docker 镜像导入导出：离线环境下的镜像迁移指南</title>
    <id>https://www.fen9pi.cn/posts/docker-image-import-export/</id>
    <link href="https://www.fen9pi.cn/posts/docker-image-import-export/"/>
    <updated>2026-10-14T11:02:37.000Z</updated>
    <summary type="html"><![CDATA[<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="Docker 镜像导入导出"></p>
<blockquote>
<p><strong>离线环境、网络隔离、跨服务器迁移...</strong></p>
<p><strong>当你无法直接 pull 镜像时，</strong></p>
<p><strong>Docker 镜像的导入导出就是你的救星。</strong></p>
</blockquote>
<hr>
<h2>为什么需要镜像导入导出？</h2>
<p><strong>常见的场景：</strong></p>]]></summary>
    <content type="html"><![CDATA[<p><img src="/images/unsplash/photo-1518770660439-4636190af475-40sbgd.jpg" alt="Docker 镜像导入导出"></p>
<blockquote>
<p><strong>离线环境、网络隔离、跨服务器迁移...</strong></p>
<p><strong>当你无法直接 pull 镜像时，</strong></p>
<p><strong>Docker 镜像的导入导出就是你的救星。</strong></p>
</blockquote>
]]></content>
    <category term="开源拆解"/>
    <published>2026-06-22T00:00:00.000Z</published>
  </entry>
</feed>