<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>OpenSpec on FF的实验笔记</title>
    <link>http://blog.memcd.com/tags/openspec/</link>
    <description>Recent content in OpenSpec on FF的实验笔记</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>(c) 1998 - 2026</copyright>
    <lastBuildDate>Sun, 26 Apr 2026 16:46:40 +0800</lastBuildDate>
    <atom:link href="http://blog.memcd.com/tags/openspec/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>OpenSpec：一句话完成一个独立软件开发</title>
      <link>http://blog.memcd.com/posts/ai/2026-0426-openspec/</link>
      <pubDate>Sun, 26 Apr 2026 16:46:40 +0800</pubDate>
      <guid>http://blog.memcd.com/posts/ai/2026-0426-openspec/</guid>
      <description>&lt;h1 id=&#34;openspec一句话完成一个独立软件开发&#34;&gt;OpenSpec：一句话完成一个独立软件开发&lt;/h1&gt;&#xA;&lt;!-- &#xA;OpenSpec：交出你的最后一份工作&#xA;OpenSpec：Agent独立的最后一块版图&#xA;OpenSpec：一句话完成一个独立软件开发&#xA;时间成本：&#xA;- 实验：3小时&#xA;- 文章：3小时&#xA;--&gt;&#xA;&lt;h2 id=&#34;概述&#34;&gt;概述&lt;/h2&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;在项目目录 &lt;code&gt;openspec init&lt;/code&gt;&lt;/li&gt;&#xA;&lt;li&gt;在你的IDE里，执行 &lt;code&gt;/opsx-propose 一句话需求描述&lt;/code&gt;，spec自动分析为什么要这么做、需求和场景是什么、技术方案定义和实施任务清单，并在changes目录生成相关规范文档&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;/opsx-apply&lt;/code&gt; 根据changes目录的规范文档，逐条开发，直到全部任务清单都被完成&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;/opsx-archive&lt;/code&gt; 将本次需求归档到archive目录下，需求开发完毕&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;本文通过openspec进行实践，只用了&lt;code&gt;20分钟 + 3美金&lt;/code&gt;的成本，就实现了多渠道新闻聚合功能，类似早期版本今日头条。&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;故事&#34;&gt;故事&lt;/h2&gt;&#xA;&lt;p&gt;从去年4月开始付费使用Windsurf算起，正式开始使用Agent产品已经超过一年。这一年来，随着Agent产品和大模型技术的不断发展，Agent可以做的事情越来越多，从早期只用来生成一些测试脚本，到现在可以把大型项目完全交给Agent去生成，这进步速度简直太快了。&lt;/p&gt;&#xA;&lt;p&gt;虽然现在Agent已经强大无比，但是在平时工作中，还是有一小部分事情我是习惯由人来完成，而不交给AI。就是整体技术架构设计和产品的需求管理工作。产品目录可能类似如下结构：&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;.&#xA;├── 01.brd 商业需求文档&#xA;├── 02.mrd 市场需求文档&#xA;│   ├── ca 竞品分析&#xA;│   ├── users 用户分析&#xA;├── 03.prd 产品总体需求说明&#xA;├── 04.version 版本需求说明&#xA;│   ├── v1.0.0.md&#xA;│   ├── v1.0.1.md&#xA;├── 05.technology 产品技术架构设计&#xA;├── 06.operation 产品运营&#xA;├── src 源代码，交给AI&#xA;├── Makefile 管理整体构建和发布&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;姑且给我在使用的这种工作方式，称为“古法Agent开发”。&lt;/p&gt;&#xA;&lt;p&gt;除了src源代码部分全部交给AI，其他部分还是由人来把握。因为在实践中发现，AI哪怕有了memory，但是实际做事的时候还是容易跑偏和缺乏宏观视野，解决技术和产品细节问题的时候往往会忽略战略方向和原则。如果源代码已经完成落地，再进行大幅调整，不仅仅会危害技术架构（缺乏整体规划的反复局部修改会导致技术架构腐化），还会导致巨幅的token消耗，直接推高产品的研发成本。&lt;/p&gt;&#xA;&lt;p&gt;把这些产品研发中核心的工作继续交给人来掌控，可以在每个版本开发工作结束的时候，要求AI评估是否跑偏。例如为满足当前版本需求修改了接口，那所有调用该接口的代码和设计要统一进行修改并确保通过单元测试；例如已经被战略规划为付费功能的功能点，就不能在开发免费功能的时候顺手给开发进免费功能里。这些都是在实践中实际踩过的坑。&lt;/p&gt;&#xA;&lt;p&gt;Agent现在可以独立接手全部代码工作，已经是时代的巨大进步，人只掌握核心的原则和方向，这把人从代码细节中解放出来，可以进行更宏观的思考，是人力资源的巨大解放。等于是，人的价值被提高了。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
