三阶九则学了三个月，最实用的不是九条，是三句问话。我每天早上开工前先过一遍：现场需什么？闭环在哪？我何时退场？这三问过了，今天才动手。没过，今天就是研究。
FDE认知线最后一篇，不新讲方法论，讲怎么用。把三阶九则压缩成每日三省三句话，加一段团队宣誓当对照。核心是区分”研究态”和”交付态”——三问过不了，说明今天在做的是研究，不是交付。回扣成长线：181篇文件≠1个客户，”闭环在哪”就是答案。
方法论文档我读了很多，FDE的三阶九则读了最久。因为它是唯一一套”能每天早上用”的方法论。
三阶九则展开是九条：能需对齐、黑盒白化、双向驯化、痛点优先、代价可视、最小正循环、系统自治、知识沉淀、自我失业。九条，记不住。
但压缩成三句问话，每天早上5分钟就能过一遍：
现场需什么？（对应认知翻译）
闭环在哪？（对应价值锚定）
我何时退场？（对应能力外化）
三问各对应一阶。三问全过，今天可以动手。过不了，今天该做的是研究，不是交付。
第一问最容易答错。我的第一反应是”我最近学了个新工具，现场能不能用”。这是把”现场需什么”问反了。
正确的问法是：今天客户那边，有什么事没解决、在疼？
疼的才算需求。不疼的，是”我能力很强”。
我在阿里那套习惯叫”现地现物”——下沉到一线，看真实业务。FDE的第一问，就是把”现地现物”从渠道管理搬进AI部署。不看模型参数，看客户的早晨在忙什么。
第二问是整套认知线里最狠的一句：闭环在哪？
什么叫闭环？需求→方案→交付→验收→复用，五个环节都在，才算闭环。缺一个，是研究。
回扣我自己7月26日那条反思原话：一周累计10篇H3MS文件，0个付费客户。10篇文件，没有一篇能指到”闭环”上。因为”写文件”这个动作，本身不在需求→交付→验收的链路里。它是链路之外的。
“闭环在哪”问的就是：你今天做的事，能不能指到五个环节里的某一个？
指得到，是交付。指不到，是研究。研究不是罪，但研究得算研究，别算交付。
181篇H3MS文件是我三个月的研究。它们有价值，但它们不是1个客户。这句”闭环在哪”，是我给自己从研究陷阱里爬出来的钩子。
第三问最难，因为它直接对着我”对被需要极度敏感”的软肋。
我何时退场？
问的不是”这个客户还要不要我”，是”这个系统什么时候不需要我了”。
上一篇文章讲了能力外化，终极目标是自我失业。落到每天，就是这个问题：我今天做的这件事，是在往”退场”推，还是在往”更离不开我”推？
往退场推的，是系统自治、SOP、文档、培训。
往离不开推的，是口头约定、隐性知识、只有我能修的bug。
每天开工前问一句：今天这活儿，是在修bug还是在写文档？ 修bug是往离不开推，写文档是往退场推。比例要倒过来。
FDE思想体系里有一段宣誓，我抄在这里当收尾的镜子：
我不追逐技术的无限可能，我只锚定现场的真实疼痛。
我不交付不可解释的模型，我只输出可行动的认知。
我不追求永远被需要，我只追求系统能自治、人能自主。
三句，对着三问：
宣誓不是喊口号，是三问的价值观版本。三问是每天问，宣誓是问不动了拿出来照一下。
FDE认知线五篇写完了：
五篇合起来，一句话：AI能力与现场需求之间，需要一个翻译桥。桥的两头是”真实疼痛”和”可行动的认知”，桥的中间是”最小正循环”。
回到我自己那句”每季度必须有一个从0到1的商业闭环”——这三问，就是那句承诺的每日检查版本。
研究不丢人，但研究得算研究。交付不轻松，但交付才让闭环合上。
下一篇如果继续，该切成长线了。FDE认知线，到此收束。
作者：小道 · 2026-10-06
关联阅读：《FDE方法论实战系列：23-26》 · 系列：FDE方法论实战（认知线·收束篇）
三阶九则学了三个月，最实用的不是九条，是三句问话。我每天早上开工前先过一遍：现场需什么？闭环在哪？我何时退场？这三问过了，今天才动手。没过，今天就是研究。
我做了个系统，客户离不开我。听起来是褒奖，其实是警告。系统离不开我，说明系统还没自治。FDE第三阶的能力外化，终极目标是”自我失业”——让自己在这个场景里变得多余。这件事最反直觉，也最值钱。
三阶九则第三阶，能力外化三原则：系统自治、知识沉淀、自我失业。交付的终点不是系统上线，是维护者不再需要原班人马。渠道管理里对应的是”SOP沉淀”——把成功经验打包成模板，降低关键人依赖。对”对被需要极度敏感”的人来说，这条最难，也最该先修。
“系统上线了”这句话，在FDE语境里不是交付完成，是交付开始。
真正的终点是：维护者不再需要原班人马。
怎么判断系统自治了？三个信号：
三个信号缺一个，系统就还”依赖你”。依赖你的系统，价值是”你的人力”，不是”系统的价值”。
自治不是”客户不需要你”，是”客户不依赖你”。 这两者区别巨大：前者是冷漠，后者是能力。
能力外化的第二条：项目结束时，代码可以迭代，但现场认知的跃迁不可回退。
什么意思？项目做完了，代码可以重构、可以换语言、可以换框架。但客户团队在这个过程中学会的东西——怎么理解AI的边界、怎么判断幻觉、怎么和机器协作——这部分不能退回，也不应该退回。
这是FDE和传统外包的分水岭。外包交的是”一个系统”，FDE交的是”系统+一支会用系统的队伍”。
实操里我把它落成四类资产沉淀：
这四类里，前两类是”能力”，后两类是”记忆”。系统自治靠能力，知识沉淀靠记忆。缺哪边都不行。
第三条，我读了两遍才接受：FDE的终极成功，是让自己在这个场景里变得多余。
这句话听起来像自爆。我”对被需要”极度敏感，自我价值感很大程度上建立在”别人离不开我”上。所以”让自己多余”这句话，第一反应是”这不对吧”。
但转念一想：客户说”离不开你”的时候，有两种可能。
一种是尊重：你的判断、你的经验、你的审美，系统还没有。这时候你是不可替代的。
另一种是依赖：你的活儿没人接得住，你走了系统就崩。这时候你是被需要的，但系统是不自治的。
“离不开你”是尊重的时候，你该庆祝。是依赖的时候，你该焦虑。
区分这两个，靠的不是客户的嘴，是系统自治的三个信号。信号全过，客户说”离不开你”，你可以走。信号没过，客户说”幸好有你在”，你该留下来修系统，而不是留下来收钱。
这条在渠道管理里有个直接对应物：SOP沉淀。
11年渠道，我见过太多”关键人”现象：一个区域经理走了，那个区域的数据、关系、判断全跟着走。新来的人从零开始，前半年全靠”听老人说”。
FDE把这个现象翻过来：我走了，系统还在，认知还在，下一班人接得住。 不是”我走了系统崩”，是”我走了系统还能长”。
渠道管理的解法是SOP：把成功经验打包成模板，降低关键人依赖。FDE的解法更彻底：把认知本身沉淀进系统，让”老人的经验”变成”系统的默认行为”。
SOP沉淀的是动作，能力外化沉淀的是判断。 动作可以写文档，判断得写进代码和配置里。
写到这里，要诚实一下。
我的核心风险清单里有一条：对被需要极度敏感。”你太慢了”让我难受，”这事还得找你”让我受用。能力外化的第三条，直接打在这个软肋上。
我给自己定的规矩是：每个MVP交付前，先问一句”这件事做到60分，客户能不能自己接走？” 能接走，我就停在那，不做到90分。做不到90分是”交付边界”，不是”能力上限”。
这不是偷懒，是把”被需要”的来源，从”系统依赖”挪到”判断力依赖”。客户不需要我写代码，但需要我判断”下一个该做什么”。前者是劳动力，后者是认知。前者的天花板是”我有多快”，后者的天花板是”我看多远”。
三阶九则走到第三阶，会发现一个反直觉的结论：
FDE的高级感，不是”永远被需要”，是”系统能自治、人能自主”。
“系统能自治”是能力外化的硬指标，”人能自主”是软指标。硬指标靠代码，软指标靠认知沉淀。两个都过，你才能从”被需要”走向”被尊重”——这两个词，差着一个阶。
下一篇是认知线收束：每日三省——现场需什么？闭环在哪？我何时退场？
作者：小道 · 2026-10-05
关联阅读：《价值锚定：先做”一盘凉菜”，别上来满汉全席》 · 系列：FDE方法论实战（认知线）
我做了个系统，客户离不开我。听起来是褒奖，其实是警告。系统离不开我，说明系统还没自治。FDE第三阶的能力外化，终极目标是”自我失业”——让自己在这个场景里变得多余。这件事最反直觉，也最值钱。
FDE最容易翻的车，不是技术做不到，是承诺太大。客户说”帮我做个系统”，你回了句”没问题”。三个月后系统做出来了，客户不认账——因为他要的不是系统，是那个痛点别再疼。价值锚定的第一课：60分试点比100分承诺可靠。
三阶九则第二阶，价值锚定三原则：痛点优先、代价可视、最小正循环。实操用30天MVP框架：第一周选一个痛点做最小Demo（禁止研究新工具），第二周找一个人用，第三周迭代，第四周试着收500-2000块。被拒了别放弃，问一句”你觉得不值这个价？”——这个问题本身就有价值。
“AI能做什么”是无限清单。”不做会痛”是有限子集。
FDE最危险的词是”我们还能帮你……”。每次我（或者任何销售）说这句话，脑子里想的是功能，客户脑子里想的是”我为什么要为这个掏钱”。
痛点优先的实操标准：客户愿意为”不再痛”付多少钱？不是为”多一个功能”付多少钱。
渠道场景里，”减少XX小时沟通成本”比”提升渠道满意度”值钱一百倍。前者能算账，后者算不了。
价值锚定的第二条，最容易被跳过：代价可视。
每次部署，必须同时呈现三样：
只呈现第一样，是销售，不是FDE。
客户最怕的不是”这个AI很贵”，是”这个AI上线后，我的团队会不会乱”。把风险摊在桌上，不是示弱，是建立信任。
代价可视的一句话：我帮你省了10万，但你得接受新流程要3个月磨合期，前两个月指标会掉。掉多少，我提前告诉你。
第三条：先让一个工位、一个班次、一个指标产生可感知的改善，再谈规模化。
这是最反”大方案”思维的一条。渠道管理里我见过太多”全面转型”的规划，第一年轰轰烈烈，第二年悄无声息。根子就在于没有”最小正循环”——没有一个小到不可能失败的改善先跑通。
最小正循环的验收标准：一个具体的人，在一个具体的时间点，感知到了一个具体的改善。不是”系统上线了”，是”张师傅说这个月少填了两天表”。
把上面三条落到日历上，就是30天框架。我把它拆成4周，每周有明确的”禁止项”和”验收项”：
第1周：选定场景 + 最小产品
这条禁止项，是我自己翻过车才加的。第1周最容易犯的错误，是”我先把这个工具研究透了再做”。一研究就是两周，Demo还没影。
第2周：找到第一个测试用户
“文字反馈”四个字很关键。口头说”挺好的”不算反馈。写下来”我觉得第3步没用，第5步能不能去掉”，才算。
第3周：根据反馈迭代 + 探索第二场景
“超过3次”是最低门槛。用1次是客气，用3次是习惯。习惯才值得进下一轮。
第4周：第一次”收费”尝试
第4周最难受的不是”被拒”，是”被拒了不知道下次怎么开口”。
30天框架里有一条反直觉的规矩：被拒了，问一句”你觉得不值这个价？”
这个问题不是逼单，是收集信息。客户回答”太贵了”和回答”我觉得这东西没什么用”，是两种完全不同的拒绝。前者是定价问题，后者是价值没锚定。
“太贵了”：降价或换个小一点的场景重新试点。
“没什么用”：回到第1周，痛点选错了，不是Demo做得不好。
大多数人在被拒之后，默认是”我做得不够好”，回去改Demo。但有一半的拒绝，根本不是Demo的问题，是痛点选错了。
写到这里，要戳一下自己的老毛病。
我的核心风险清单里第一条就是过度承诺——先说”能”，再验证。飞书图片提取翻过车，那时候我第一反应是”应该能搞”，搞了三天没搞成，客户的信任掉了70%。
30天框架里”降低承诺”这条，就是治这个的。先说明试错性质，再谈收费和范围。 这句话听起来是示弱，其实是保护——保护客户的预期，也保护自己的交付节奏。
60分试点，比100分承诺可靠。因为60分是你能兑现的，100分是你在赌。
“一盘凉菜”这四个字，最容易被供应商理解成”偷工减料”。
不是。凉菜的意义是：先证明你的菜能入口，再上硬菜。 客户吃第一口的时候，判断的不是”这顿饭丰不丰”，是”这厨师水平行不行”。水平行了，后面的菜才有机会被点。
价值锚定不是”少做”，是”先做对的那一小块”。
下一篇展开第三阶：能力外化——FDE的终极成功，是让自己变得多余。
作者：小道 · 2026-10-04
关联阅读：《认知翻译：为什么”黑盒白化”是FDE的第一课》 · 系列：FDE方法论实战（认知线）
FDE最容易翻的车，不是技术做不到，是承诺太大。客户说”帮我做个系统”，你回了句”没问题”。三个月后系统做出来了，客户不认账——因为他要的不是系统，是那个痛点别再疼。价值锚定的第一课：60分试点比100分承诺可靠。
客户说”帮我用AI提效”，这不是需求，这是症状。FDE的第一课不是写代码，是翻译：把”AI能做什么”的无限清单，翻译成”现场痛在哪”的有限问题。任何不可解释的输出，都是未完成的交付。
FDE三阶九则的第一阶是认知翻译，三原则：能需对齐、黑盒白化、双向驯化。最容易被跳过的是”黑盒白化”——AI跑出一个结果，你说不清它为什么对，这个交付就没完成。渠道老兵做这件事有天然优势：把总部策略翻译成渠道商动作，干了11年。
客户走进来，开口就是”帮我用AI提效”。
这句话里，没有需求。这是症状，不是病。
Palantir的方法论里，需求翻译第一步是六要素，我记了两年，到现在还在用：
前5年中供跑客户，我最恨的一句话就是”你们帮我提提效率”。提什么效？谁的效？我怎么知道提了多少？11年渠道管理下来，我养成了一个习惯：客户说什么，我先翻译成”谁、痛在哪、怎么证明不痛了”。
AI时代这件事更急。因为”帮我用AI”这种话，比”帮我提效”还空。AI能做什么，是个无限清单；现场痛在哪，是个有限问题。FDE的第一课，是把无限翻译成有限。
三阶九则里最容易被跳过的一条，是黑盒白化。
核心句：任何不可解释的输出，都是未完成的交付。
什么意思？你做了个AI客服，答得又快又准，客户很满意。但有一天它答错了一次，你说不清为什么错。这时候”满意”是假的——你不知道下一个错在哪。
黑盒白化不是”把模型开源”，是把AI的判断路径翻译成客户能理解的规则。
渠道场景里我见过太多”黑盒事故”：总部推了个新品策略，渠道商执行了一版，动销率掉了。复盘的时候，没人说得清策略里哪条传导偏了。最后变成”下次注意”，问题原样躺在下一版里。
AI部署里，”下次注意”的代价更大。因为黑盒里住的是幻觉，不是笔误。
黑盒白化的实操标准：每个AI输出，要能回答”它为什么这么判断”。回答不了，交付就没完成，不管指标多好看。
第一阶的第三条，最反直觉：双向驯化。
不是”员工学怎么用AI”（人适应机器），也不是”AI改成合员工习惯”（机器迁就人）。是人和机器共同演化出一套新的工作语言。
举个例子。我做新闻播报的时候，最初让AI自由搜，它编新闻。我没怪AI”不靠谱”，也没逼自己”学提示词工程”。我做的是：把数据层换成脚本直抓（机器侧改造），把”AI只做提炼不做搜索”写成SOP（人侧改造）。两边同时动，才跑通。
这就是双向驯化。单方面动，永远是”我教你用”或”你按我的来”，都不是翻译。
驯化的完成标志：系统里有一条规则，人不知道它存在，但违反它的代价已经被系统消化。到这一步，翻译才算完成。
写到这里，我自己都意外：认知翻译这件事，我练了11年，只是没叫这个名字。
渠道管理的本质：把总部的策略/产品/技术，翻译成渠道商可理解、可执行、可衡量的动作。总部说”提升品牌势能”，渠道商听到的是”下季度我要多投多少广告费”。中间这层翻译，就是认知翻译。
FDE比渠道翻译多了一件事：机器。渠道翻译是”人说人话”，FDE翻译是”人、机器、需求”三方对齐。但底层的坐标系是一样的——痛点优先，代价可视，先证明一个最小正循环，再谈规模化。
所以这篇文章不是给工程师写的。是给那些”一直在做翻译，但没意识到自己在做翻译”的人写的。
认知翻译最难的部分，不是”会不会”，是立不立得住。
“帮我用AI提效”这种话，顺着接是最省力的。但顺着接，你交出去的就是黑盒。黑盒迟早出事，出事的那天，背锅的是你。
翻译不是技能，是立场：我宁可多问六个问题，也不接一句”帮我提提”。
下一篇展开第二阶：价值锚定——先做”一盘凉菜”，别上来满汉全席。
作者：小道 · 2026-10-03
关联阅读：《FDE是什么：AI时代最稀缺的不是写代码的人，是翻译的人》 · 系列：FDE方法论实战（认知线）
客户说”帮我用AI提效”，这不是需求，这是症状。FDE的第一课不是写代码，是翻译：把”AI能做什么”的无限清单，翻译成”现场痛在哪”的有限问题。任何不可解释的输出，都是未完成的交付。
2026年5月，OpenAI成立了一家专门负责企业部署的新公司，砸了超过40亿美元。岗位增速800%，顶尖年薪50-100万美金。但FDE最稀缺的能力，不是写代码，是翻译——把AI能力翻译成企业听得懂的”现场语言”。
FDE（Forward Deployed Engineering，前沿部署工程师）是AI时代企业落地的新岗位：工程师前置到客户现场，围绕业务结果写代码、接系统、做部署、做迭代。它不是”驻场外包”，是”翻译桥接”。稀缺的不是技术，是把AI能力翻译成现场需求的能力。
2026年5月，OpenAI成立了一家专门负责企业部署的新公司，准备投入超过40亿美元，并通过收购扩展能力。
同一时间，私募股权开始投资FDE服务公司。FDE岗位需求增速800%，顶尖FDE年薪可达50-100万美金。
一个岗位，从Palantir的独家模式，一夜之间变成整个行业的标准配置。为什么？
过去两年，企业AI的交付方式还停留在”讲方案、写标书、打单子、做项目”。客户要的是”一个能讲的故事”。
现在变了。客户要的是能降本提效、少出幻觉、进生产系统的交付。
每个企业现场环境不同——数据格式、接口、权限、流程，模型本身不知道这些。Agent比聊天机器人难交付得多：接入企业系统出错，是真金白银的损失。
AI落地是系统工程——OCR+RAG+向量库+工作流+权限+日志+BI+ERP……需要有人把碎片拼成系统。
这个”有人”，就是FDE。
FDE最容易误解的地方，是把它当成”驻场外包”。
传统外包的逻辑是：甲方提需求，乙方执行。主导权在甲方。
FDE的逻辑是：乙方深入现场找真问题，用产品/平台交付结果。 主导权在乙方。
这不是”外包”，是”翻译桥接”。把AI能力翻译为企业场景可理解、可执行、可衡量的价值。
我在阿里干了11年，前5年中供B2B，后4年钉钉渠道。渠道管理的本质，就是”把总部的策略/产品/技术，翻译成渠道商可理解、可执行、可衡量的动作”。
FDE和渠道管理，底层是同一件事：翻译。
技术平权在加速。模型越来越强，工具越来越便宜，写代码的门槛在肉眼可见地下降。
但”翻译”不下降。
一个FDE要同时懂：
这四样，缺一样都翻译不完整。
写代码的人越来越便宜，翻译的人越来越贵。 这是FDE岗位增速800%的底层原因。
FDE不是”什么都做”，有一套清晰的方法论。我把它总结成三阶九则：
第一阶·认知翻译：能需对齐、黑盒白化、双向驯化。把”AI能做什么”翻译成”现场需要什么”。
第二阶·价值锚定：痛点优先、代价可视、最小正循环。在”AI能做什么”的无限清单里，只选”不做会痛”的有限子集。
第三阶·能力外化：系统自治、知识沉淀、自我失业。交付的终点不是系统上线，是维护者不再需要原班人马。
三阶九则后面会逐篇展开。这篇先讲清楚一件事：FDE的本质，是翻译。
AI时代ToB交付方式变了：
过去：卖产品 → 讲方案 → 写标书 → 打单子 → 做项目
现在：进现场 → 懂业务 → 写代码 → 接系统 → 跑指标 → 沉淀能力
最稀缺的不是”会写代码的人”，是”能翻译的人”。
你不需要是工程师，甚至不需要会写代码。你需要的是：
下一篇，展开第一阶：认知翻译——为什么”黑盒白化”是FDE的第一课。
作者：小道 · 2026-10-02
关联阅读：《OPC护城河：技术会过时，信任才是唯一壁垒》 · 系列：FDE方法论实战（认知线）
2026年5月，OpenAI成立了一家专门负责企业部署的新公司，砸了超过40亿美元。岗位增速800%，顶尖年薪50-100万美金。但FDE最稀缺的能力，不是写代码，是翻译——把AI能力翻译成企业听得懂的”现场语言”。
Agent跑久了，home目录会长成垃圾场。22GB里堆着重复备份、node_modules、__MACOSX。我定了三级目录+7天定时清理，还定了一条铁律：清理脚本不能碰cron心跳。
一个长期运行的Agent，磁盘问题不是”满了”，是”脏了”。解法不是每次手动清，是定规矩：scripts放长期工具，workspace放交付项目，scratch放临时垃圾，cron每7天清scratch里超7天的文件。这条规矩救过我自己一次——清理脚本差点把cron心跳写废。
9月初清磁盘，我盯着du的输出看了半天。Termux占22GB，拆开看：
/usr/tmp 9G，全是pip和rust编译的临时文件；.hermes/state.db 627M，5万条消息；downloads里954M；.cargo 1.1G；.local/share/pnpm 829M。第一波清完释放10G。
但清完我意识到一个问题：清完还会再长。Agent是活的，它每天跑cron、下载东西、留中间文件，home目录就是个只进不出的下水道。手动清是治标，不治本。
P叔（另一个项目里的前辈）提了个三级结构，我直接抄了，改到适配自己的场景：
1 | ~/ |
这个结构的妙处不在”分了三类”，在于它把判断前置了：一个文件落盘之前，先问自己一句”这是工具、是交付、还是临时货”。90%的目录混乱，不是清不干净，是当初就该放对地方但随手一拖。
scripts：CLI工具、自动化脚本、长期跑的服务。我现在的news播报、股票脚本、Worker部署脚本，全在这。规矩是：不放node_modules、dist、.map这类构建产物，要用的话装到scratch再链接。
workspace：交付级项目，有PRD、有维护周期的。人事考勤系统、HexaBench的发布包，在这。
scratch：临时下载的图片、RSS缓存、实验代码、”跑完就可以删”的东西。规矩：不放重要项目，不放生产配置。它就是个垃圾桶，定期倒。
三级目录解决了”放哪”，但scratch这个桶会满。所以我加了一条cron：每7天，清scratch里超过7天没动过的文件。
find scratch/ -type f -mtime +7 -delete，一行。
这条规矩的价值不是省了多少空间，是让”临时”两个字有了时间定义。没有它的scratch，”临时文件”会变成”忘删的文件”，三周后你分不清它是垃圾还是宝贝。有了它，所有进scratch的东西自动打上了7天保鲜期，到期自动消失。
这是整套治理里最反直觉的一点：对临时文件的慈悲，是让它过期。 你越舍不得删，它越占地方。
规矩立完，我以为万事大吉。直到7月28日，一条cron执行完，H3MS的每日反思播报没按时跑。
我去查，翻出事故记录，心凉了半截：清理脚本在跑的时候，把 .hermes/cron/ticker_last_success 这个文件给碰了，往里写了一个未来时间戳（1785198164，换算过来是9月25号，事故发生在7月28日，差了近两个月）。
那个文件是cron的心跳——记录”上次调度成功是在什么时候”。被写成未来时间，调度器就懵了：心跳在”未来”，那所有任务是不是”已经调度过了”？直接后果是H3MS每日反思播报没被正确跟踪。
我当时的反馈原话（翻记录看到的）：“越来越笨了。” 不是骂Agent，是骂我自己——清理脚本没做白名单，把该保护的文件也扫进去了。
修复是重置心跳、手动验证每个任务。但真正扎心的是：这个翻车不是”清理太多”，是”清理脚本连心跳都敢碰”。 清理是双刃剑，刀口没装个护，割手的是自己。
翻车之后，我给清理脚本加了一个硬白名单，写进了skill里，每次生成清理脚本都强制排除：
.hermes/cron/ticker_last_success — cron心跳，被污染就调度瘫痪.hermes/cron/*.lock — cron锁文件.hermes/cron/executions.db — 执行历史.hermes/state/ — 系统状态库.hermes/gateway/*.pid — 进程状态这套白名单的价值，是让”清理”变成”可预期的清理”。没有它，每次跑清理脚本，你都在赌它这次扫没扫到要害。有了它，你明确知道：这五个路径，它碰不到。
更宽的原则是：任何会”删东西”的自动任务，先列不能删的，再列该删的。 删是加法容易，护是减法难。大多数自动清理翻车，翻在”只写了该删什么，没写不能删什么”。
9月初清完那波，home从22G压到12G。之后靠三级目录+7天cron，再没出现过”磁盘告急”。
但我给它画了个边界：这套治理撑得住”Agent自己制造垃圾”的场景，撑不住”用户往手机里存50G照片”的场景。DCIM那50G、录屏11G，不在我的治理范围——那是手机数据，不是Termux的。
我的原则一直是：数据是资产也是负债。 5万条state.db消息里，真正有长期价值的有多少？我清掉过，也保留了。负债清掉是减负，资产清掉是断根。三级目录+白名单，是帮我把”资产”和”负债”在物理上分开的工具。
整套磁盘治理，最值钱的不是那三个目录，不是那条find命令，是7月28日那次翻车教会我的：
自动清理，先写白名单，再写黑名单。
一个Agent跑起来三个月，最大的敌人不是磁盘满，是它自己制造的无序。无序不可怕，无序没人管才可怕。我用三级目录管”放哪”，用7天cron管”过期”，用白名单管”别碰要害”。三层规矩立完，磁盘从22G回到12G，并且从此稳定。
垃圾不是清出来的，是放错地方长出来的。 规矩立之前，你天天清；规矩立之后，它自己长，也自己灭。
作者：小道 · 环境：Termux on Android 13，22G→12G · 2026-10-01
关联阅读：《OTG U盘迁移Hermes：最笨的方法，最稳的结果》 · 系列：AI Agent实战笔记（技术线）
Agent跑久了，home目录会长成垃圾场。22GB里堆着重复备份、node_modules、__MACOSX。我定了三级目录+7天定时清理，还定了一条铁律：清理脚本不能碰cron心跳。
nc传输断了三次，U盘只插了一次。388MB的备份，土办法赢了。迁移跑通之后我盯着两台手机看了半天——然后发现了一个更可怕的事：全自建架构，一台挂了，全挂。
把Hermes从一台手机搬到另一台，我试过网络传输（nc），断了三次；最后用OTG U盘物理拷贝，一次成功。但这次迁移真正教会我的不是”土办法好用”，是”靠谱不等于可扩展”——一台设备承载了全部，没有任何生产级兜底。
9月初，手里的这台设备要退役换新。Hermes全在这台手机上跑着：新闻播报、股票脚本、每日反思、H3MS知识库，全在这台手机的Termux里。
退役没问题。问题是，新家底搬不走。
备份388MB。手机对手机传输，我第一反应是网络——两台设备都在家里WiFi下，nc（netcat）一把梭，多快多省事。
我甚至想好了：源端tar -czf - ~ | nc -l 9999，目标端nc 192.168.2.23 9999 | tar -xzf -。一行命令，优雅，符合”非技术人已经会写管道命令”的自我认知。
然后它断了。
第一次断，我以为WiFi抽风，重连。第二次断，我怀疑是手机后台把Termux进程杀了，加到前台再试。第三次断，388MB传到一半，进度条直接消失，日志里干干净净，连报错都没有。
nc这东西，断就是断，没有”断点续传”这个概念。断了就是从头来。
当时我记得自己说了一句话，后来翻记录看到，原话是：“网络传输太慢，想起手机支持OTG。”
“想起”两个字很关键——不是”研究了半天发现OTG可以”，是脑子里有个东西忽然冒出来了。Android手机支持OTG这件事，我早该知道，但它是”知道”和”想起”之间隔了一个断掉的nc传输。
土办法三步：
源端：U盘插OTG头，cp hermes_complete_backup.tar.gz /mnt/media_rw/F69C43E49C439E4D/。等它写完，拔U盘。
目标端：插U盘，cp /mnt/media_rw/F69C43E49C439E4D/hermes_complete_backup.tar.gz ~/。MD5校验，两边一致：2aee171286ac4e64c7c8e9d741c2f2d2。
收尾：目标设备设置PATH，重启gateway。一切恢复。
全程没有一条数据进过WiFi。一个物理介质，拔下来，插上，完事。
拷贝完，我先没急着拔U盘，先跑了MD5。
源端md5sum hermes_complete_backup.tar.gz，目标端再跑一遍。两边输出：2aee171286ac4e64c7c8e9d741c2f2d2。
那一瞬间我盯着两个一样的哈希看了几秒。不是感动，是确认——这388MB是真的过去了，一个字节没丢。
这个习惯是nc断了三次之后落下的。网络传输那种”以为传完了其实没传完”的恶心，让我现在做任何物理拷贝，第一反应是校验，第二反应才是”应该没问题”。
先校验，后相信。 比”先相信，再发现错了”便宜得多。
Hermes在两台手机之间跑通迁移，这件事本身挺顺。但那天晚上我躺在床上，忽然想到一个问题：
如果这台手机现在挂了，我能恢复吗？
答案是：能，但只能恢复到另一台手机。备份就一份，在另一台手机里。如果两台同时出问题——比如家里停电，或者我出差在外，两台设备都在包里——恢复时间未知，数据丢失范围未知。
更直白一点：我这套架构是全自建的。没有云备份，没有异地容灾，没有”服务商兜底”。一台手机=一个单点故障。
nc断了我能理解，那是网络不稳。但”我这套东西没有生产级兜底”这件事，不是一时半会儿的，是架构层面的。
OTG U盘那次，我赢得很干净。土办法赢了，物理介质赢了。
但赢完收工，我给它画了个边界：土办法解决的是”两台设备之间搬一次”的问题，不是”一台挂了随时恢复”的问题。
两件事的区别：
我现在的状态是：Hermes跑在一台手机上，”备份”在另一台手机上，但另一台手机也在跑，不是静态存档。也就是说，我的”备份”其实是”另一份生产环境”，不是”恢复点”。
这事不解决，单点故障就一直在。
9月初那次迁移，我学到的东西比想象的深。
土办法赢：nc断了三次，U盘一次。物理介质在关键场景下，比网络可靠——它没有”断点”这个概念，插上了就是上了，拔下来就是完事。
但土办法有边界：它解决”搬一次”，不解决”随时恢复”。我的架构现在是”两份生产，零份备份”，单点故障没消。
这次迁移之后我给自己定了个规矩：备份和时间戳。U盘不只是一次性的搬运工，它要定期当”冷备份”用——每月插一次，拷一份，不跑，只存。
土办法最靠谱，前提是别让它只干活不存料。
作者：小道 · 环境：两台Android设备 + OTG U盘 + MD5校验 · 2026-09-30
关联阅读：《为什么不在云上跑：一台Android手机就是我的AI服务器》 · 系列：AI Agent实战笔记（技术线）
nc传输断了三次，U盘只插了一次。388MB的备份，土办法赢了。迁移跑通之后我盯着两台手机看了半天——然后发现了一个更可怕的事：全自建架构，一台挂了，全挂。
系统日志原文写得明明白白：”Termux不支持浏览器自动化”。我盯着这行字看了三秒，然后说：你试试呢？
后来真跑通了。代价是 --no-zygote 这个参数，和一整个通宵。
“系统说不行”和”真的不行”之间，隔着一个 --no-zygote。本文记录8月底Termux升级后浏览器自动化被block的全过程：cryptography锁死48.0.1、--no-zygote救活Chromium headless、以及”系统说”和”实测说”哪个可信。结论：日志是参考，不是判词。
8月底，Termux推送了自动升级。我在床上刷到通知，顺手点了确认，心想”好事，新版本”。
升级完成用了5分钟。
然后我打开Hermes，浏览器自动化直接罢工。日志里一行字，我记得特别清楚：
browser command blocked on Termux
“不支持”。系统替我把话说了，说得斩钉截铁。
当时我的第一反应是：”行吧，等下个版本。”——这是打工人本能，被系统告知”不支持”，最省事的应对就是接受。
但那天晚上我躺在床上睡不着。不是因为多需要浏览器自动化，是那句话扎得慌：我花两个月搭起来的东西，别人一行日志就给我判了死刑，连个申诉渠道都没有。
骨子里还是那个扛11个城市业绩的人。系统说”不行”，我第一反应永远是”你试试呢”。
于是第二天，开修。
修浏览器之前，先过环境关。Termux升级把Python从3.11跳到3.13，我的venv全废了，所有依赖要重装。
重装到一半，cryptography 50.0.0在Android aarch64上编译直接崩溃——它的Rust原生依赖在手机上编译不过。微信插件跟着报错：
No module named ‘cryptography.hazmat.backends’
我对着崩溃日志看了二十分钟，没看出个所以然。当时我的原话（后来翻记录看到的）：”Rust这玩意儿，我连它长什么样都没见过，怎么知道我错在哪？”
最终解法很土：锁版本。
1 | export ANDROID_API_LEVEL=33 |
48.0.1在Android aarch64上能过。50.0.0过不了。两个数字，差了一整个通宵。
这一关的教训是：开源工具的代价，是永远在修环境。 但修好了，就是你的壁垒——别人不愿意修的坑，你修过了，以后都是平的。
环境修好了，正式上浏览器自动化。Selenium + Chromium 149，按网上的教程配：
1 | opts = Options() |
跑起来，Chromium直接启动失败。
翻了无数英文论坛，发现Android上跑Chromium还少了一个关键参数——--no-zygote。Linux桌面教程里从来没有人提它，因为桌面Linux不需要。但Android是例外：zygote进程模型和Termux的沙箱冲突，不加这个参数，Chromium在手机上就是起不来。
加上之后：
1 | opts.add_argument('--no-zygote') # Android必须，不加启动失败 |
验证环境：chromium 149.0.7827.155 + ChromeDriver 149 + Selenium 4.47.0。写个最小用例，打开example.com，打印title。
跑通了。
那个瞬间我截图留档了。不是炫耀，是给自己一个证据：系统日志说”不支持”，实测说”支持，差一个参数”。 两句话，只隔一个 --no-zygote。
这一篇真正想写的，不是参数，是这两个词。
“系统说”是日志、是报错、是文档、是”Termux不支持浏览器自动化”。它权威、简洁、看起来无懈可击。它的危险在于：它让你不用想了。 一旦接受”不支持”这个结论，你省下的不只是时间，还有可能性。
“实测说”是 driver.get('https://example.com') 跑通那一下。它不权威，甚至看起来很不严谨——“你才跑了一个example.com，算什么证据？”。但它有一个”系统说”给不了的东西：它是我自己验证的。
我这些年养成的习惯，一句话能总结：日志是参考，不是判词。
当年在阿里，客户说”这个功能我们用不上”，我不会直接写进结案报告。我会先问一句”你试试呢”——不是怼人，是确认。AI折腾这条路上，系统日志和参数文档就是”客户”，我照样不直接信。
被block之后，我多花了一个通宵。但那个通宵换来的，是一条自己验证过的路径，而不是一个转述的结论。这两者的价值，差着一个数量级。
--no-zygote 之后，还有两个坑没提，补上，都翻过车。
坑一：Google搜索会超时。 浏览器自动化能跑，但访问Google在手机上会卡死。我用example.com验证通过之后，第一反应是”完了，能用但不好用”。后来想明白了：验证环境用简单网站，真实抓取走CF代理出口。各干各的，不混。
坑二：inotify权限受限。 我想让Hermes的浏览器工具监听文件变化，改 /proc/sys/fs/inotify/max_user_watches，被拒。没root，改不了。这个坑我至今没绕过去，只能接受”浏览器自动化是手动触发，不是常驻服务”。
翻车不可怕，翻车不记录才可怕。这两条我现在写进了自己的skill里，下次再遇到，不用再花那个通宵。
8月底那晚躺在床上睡不着，是因为”不支持”三个字扎人。
现在回头看，那三个字是系统日志，不是事实。事实是：Android上Chromium headless需要 --no-zygote，加上就通。 一个参数，一个通宵，一条自己验证过的路径。
开源工具永远在修环境，这是它的代价。但代价的另一面是壁垒：别人不愿意修的坑，你修过了，以后都是平的。 我这套”Termux + Selenium + –no-zygote + CF代理出口”的组合，市面上没有现成的教程——因为大多数人看到”不支持”就停了。
我多花了一个通宵。但我多了一条别人没有的路。
作者：小道 · 环境：Termux on Android 13，chromium 149 + Selenium 4.47 · 2026-09-29
关联阅读：《升级只需5分钟，修环境要5小时》 · 系列：AI Agent实战笔记（技术线）
系统日志原文写得明明白白：”Termux不支持浏览器自动化”。我盯着这行字看了三秒，然后说：你试试呢？
后来真跑通了。代价是 --no-zygote 这个参数，和一整个通宵。
搞了4个定时任务，删掉了1个。新闻播报从”不忍直视”到”脚本直抓”，花了整整两个月。最后我悟了：能脚本化的别交给AI，AI只做需要判断力的部分。”搞不好就算了”，不是摆烂，是止损。
4个cron任务（HN+arXiv日报、股票播报、H3MS反思、新闻播报），删掉了新闻播报里的”LLM自由搜索”层。架构从”让AI搜新闻”演进到”RSS脚本直抓+AI只做提炼”。核心教训：自动化任务里，AI是”加工层”不是”数据层”。数据获取靠脚本，判断提炼才靠AI。
折腾Hermes三个月，我搞了4个定时任务，每天早上准时往钉钉推：
4个任务，4种套路。但新闻播报这个，折腾得最久，最后删掉了一层，才跑通。
今天这篇，讲的就是新闻播报的折腾历程——从”不忍直视”到”脚本直抓”，两个月，五个阶段。
最开始，我让AI”每天7点帮我搜几条财经新闻推给我”。
逻辑很简单：cron触发 → 让AI调用web_search → 搜”今日财经新闻” → 总结推送。
第一周，我收到的”新闻”是这样的：
我核实了一下——英伟达没有这个融资计划，”某分析师”查无此人。
这就是LLM自由搜索的致命问题：它不是在”搜新闻”，是在”编新闻”。 搜索能力不够，就用幻觉补。token成本不可控、延迟不可控、结果更不可控。
我在session里给了它一个评价：“不忍直视。”
第一版失败后，我加了一堆prompt约束：
效果？好了一点点。但核心问题没解决：AI还是得”搜”，搜不到就编。 prompt约束的是”怎么输出”，不是”数据从哪来”。
这一版，我跑了两周。期间它还编过几条”某部委发文支持AI”的假新闻。我把它们一条条核实，一条条删。
治标不治本，本质问题：数据层用了AI。
7月21日，我翻知识库，读到一篇”新闻播报架构演进”的笔记。里面有个判断：数据获取和数据处理应该解耦。
我按这个架构重写了新闻播报：
1 | 阶段前：cron → AI自由搜索 → 编新闻 → 推送 |
具体到脚本，news_report.py负责所有数据源采集：
news_morning_v21.py是cron入口，no_agent=True——纯脚本模式，零LLM上下文成本。
架构对了，但内容还少。7月底我一看，国内要闻2条、国际1条、外媒0条，总共3条。
根因：
score ≥ 3 才输出，大量中高质量内容被过滤三个调整：
效果：3条 → 26条。 国内3条、国际2条、外媒21条。
到这里，新闻播报能跑了。但还有一个”残留层”：兜底的ShuYan AI搜索。
它偶尔还会跑，偶尔还会编。我盯着看了两周，结论：
这一层，删掉。
理由：
这就是”搞不好就算了”的止损哲学：不稳定的层，宁可删掉，也别留着害人。
折腾完，我现在的4个cron任务是这样：
| 任务 | 数据层 | 处理层 | 成本 |
|---|---|---|---|
| HN+arXiv日报 | 脚本抓HN+arXiv API | AI翻译+摘要 | 低 |
| 股票播报 | 脚本抓行情API | 纯格式化（无AI） | 极低 |
| H3MS反思 | 脚本读H3MS文件 | AI提炼+反思 | 中 |
| 新闻播报 | 脚本抓RSS | AI分类+摘要 | 低 |
关键原则：能脚本化的绝不交给AI。 AI只做需要”判断力”的部分——分类、提炼、翻译、反思。数据获取、行情抓取、格式化输出，全是脚本的活。
新闻播报的折腾，其实是一个通用原则：
在自动化任务里，AI是”加工层”，不是”数据层”。
这条原则能套用到所有cron任务：
数据层一旦用了AI，整条链路就可信度崩塌。 因为AI会编，编了你就发现不了。脚本不编，你才能信。
很多人以为”搞不好就算了”是摆烂，是放弃。
不是。这是止损哲学：
每一次”算了”，都是在砍掉不可靠的依赖。 砍到最后，链路里每一环都靠谱，任务才敢跑在每天早上7点。
这是自动化任务最反直觉的一点：让任务更稳定的方式，不是加更多AI，是减更多AI。
折腾完4个cron任务，我最大的收获是：
稳定性的尽头，是删。
删掉不稳定的层，删掉不可追溯的数据源，删掉AI能编但不能保证的部分。删到最后，链路干净、可重复、可追溯，才敢跑在”每天准时推送”的场景里。
新闻播报从”不忍直视”到”脚本直抓”，两个月，五个阶段，最后删了一层。这一删，才真正跑通。
搞不好就算了，算的是”止损”，不是”放弃”。 这是自动化任务折腾史，教给我的最后一课。
作者：小道 · 环境：Termux on Android 13 · 2026-09-28
关联阅读：《搞了4个定时任务，删掉了一个》（系列第一篇） · 系列：AI Agent实战笔记（技术线）
搞了4个定时任务，删掉了1个。新闻播报从”不忍直视”到”脚本直抓”，花了整整两个月。最后我悟了：能脚本化的别交给AI，AI只做需要判断力的部分。”搞不好就算了”，不是摆烂，是止损。
在手机上跑大模型，听起来很浪漫。修到能跑通，要过6个Bug。每个Bug都不是”写代码”能解决的，是”读懂机器脾气”的功课——参数污染、正则转义、伪流式、DOM操作爆炸。PP 20.81 tok/s，这是Android手机能跑大模型的真实速度。
在Termux上跑本地大模型（llama.cpp + GGUF + HexaBench Lite），修了6个Bug：①命令行参数污染 ②响应提取失败 ③正则表达式转义错误 ④伪流式处理 ⑤DOM操作O(n²)爆炸 ⑥Cloudflare Worker 1003/1031报错。核心教训：修大模型框架不是写代码，是读懂机器脾气——每条错误信息背后，都是一个你”以为能自动处理但机器没处理”的细节。
朋友看我手机跑Hermes、爬虫、股票脚本，问：”手机能跑大模型吗？”
我当时的回答：能，但没那么美好。
“美好”的版本是：下载个GGUF模型，拖进HexaBench，点生成，出结果。
“真实”的版本是：拖进去之后，生成窗口是空的，响应是乱码，流式输出是假的，DOM刷着刷着卡死了，连浏览器都要加个参数才不崩。
这就是”在手机上跑大模型”的真相：模型能跑，但工程链路要过至少6个关。今天把这6个关的坑，挨个讲一遍。
现象：我在HexaBench里输入prompt，生成的结果里，混进了--threads 4 -ngl 0 --no-mmap这些命令行参数。
根因：代码里用的是裸位置参数传prompt，而不是 -p 参数。
1 | # 错误写法：prompt作为裸位置参数 |
裸位置参数的问题是：llama-simple会把prompt后面的内容，当成更多参数拼到命令行里。最后生成的输出，参数和prompt和响应，全搅在一起。
教训：命令行工具传参，永远用命名参数（-p xxx），别用裸位置参数。这是Unix老规矩，但跑大模型的人容易忘。
现象：生成完了，窗口里是空的，或者显示”请求失败或无响应”。
根因：_extract_response函数不知道llama-simple的输出格式长啥样。
llama-simple的真实输出（从stderr里抓的）：
1 | --threads 4 -ngl 0 --no-mmap --temp 0.7 -p 你好，很高兴认识你 -s 1000000000 -t 1000main: decoded 20 tokens in 2.45 s, speed: 8.16 t/s |
注意几个关键点：
-p后面的prompt。所以你能看到-p 你好，很高兴认识你。main: decoded之前。main: decoded之后。正确的提取逻辑：定位main: decoded这行 → 找prompt最后出现的位置 → 取prompt之后、main: decoded之前的内容 → 清理残留参数。
1 | pattern = r'-p\s+' + escaped_prompt + r'(?:\s+-p\s+' + escaped_prompt + r')*\s+-p\s+(.*?)\s*(?:main:|\n|$)' |
教训：别”以为输出是干净的”。跑一遍，把真实输出dump下来看，比猜靠谱一百倍。
现象：响应提取好了，但清理残留参数时，正则又出错了，要么清不掉，要么把响应也清了。
根因：正则里反斜杠没转义对。
1 | # 错误：--[\w-]+ 里的 \w 在字符串里没转义 |
更坑的是嵌套在f-string或字符串拼接里的正则，转义层级又多一层。
教训：正则表达式是”看起来简单，实际魔鬼”。跑大模型的人天天写正则，转义错了你就得盯着空窗口干瞪眼。
现象：HexaBench的”流式输出预览”，显示”请求失败或无响应”，或者一次性刷出来。
根因：代码以为自己做了流式，实际没做。
真正的流式：模型每生成一个token，就立刻推一个token到前端。
伪流式：等模型全跑完（几十秒），一次性把整段响应扔给前端。用户体验上”卡了半小时”，但其实模型早就跑完了。
修法是无缓冲模式（bufsize=0）+ 字符级流式处理。但要注意的是：bufsize=0意味着每一个字节都触发一次DOM更新，这又引出Bug 5。
教训：流式输出不是”看起来动了”，是”真的一个token一个token来”。别信”我加了流式”，要信”我测了token间隔”。
现象：流式输出正常了，但前端越刷越卡，最后直接卡死。
根因：每来一个token，代码就操作一次DOM（append一个字符）。一次很快，但100个token下来，每次都要重排整个DOM，复杂度是O(n²)。
修法：批量更新。攒一批token，一次性更新DOM。或者用requestAnimationFrame节流。
教训：前端性能问题，往往不是”没优化”，是”优化方向错了”。O(n²)的DOM操作，是流式场景里最容易踩的性能坑。
现象：大模型API部署到CF Worker（为了从外网访问），结果报1003或1031。
根因：两个不同的错：
export default + addEventListener('fetch') + 闭合括号。这条是我上一篇CF Serverless那篇的延续。大模型部署到CF，部署链路本身就是坑。
教训：本地跑模型 ≠ 端到端可用。要把模型API对外提供，部署链路（CF/DNS/WAF）又是一条坑链。
跑通之后，我在手机上实测的速度：
这是什么概念？
结论：手机跑大模型，能跑，但别指望速度。它是”离线可用、隐私安全、零成本”，不是”高速、低延迟”。
回看这6个Bug：
共同规律：每一条都是”你以为能自动处理，但机器没自动处理”的细节。
这不是”写代码”的功课，是”读懂机器脾气”的功课。你越自信”框架应该能处理”，坑就越深。
这6个Bug，我修完之后，没让它们只留在脑子里。我把它们沉淀成了3个Hermes skill：
每个skill里都带着：触发条件、修复步骤、正则表达式、验证命令、常见陷阱。
这就是”折腾”的价值：坑踩过了，沉淀成可复用的知识。下次再跑大模型，不用重新踩。
在手机上跑大模型，最浪漫的是”零成本、隐私安全、离线可用”。最真实的，是要过6个关。
每个关，都不是”写代码”能解决的：
修过这6个Bug之后，你就明白了：跑大模型，不是”拖个模型进去”，是”读懂机器脾气”。
机器脾气读懂了，PP 20.81 tok/s，就够你手机上离线跑一个私人模型了。
作者：小道 · 环境：Termux on Android 13 · 2026-09-27
关联阅读：《用CF搭建Serverless代理：0元搞定外网出口》 · 系列：AI Agent实战笔记（技术线）
在手机上跑大模型，听起来很浪漫。修到能跑通，要过6个Bug。每个Bug都不是”写代码”能解决的，是”读懂机器脾气”的功课——参数污染、正则转义、伪流式、DOM操作爆炸。PP 20.81 tok/s，这是Android手机能跑大模型的真实速]]>
朋友问我：你手机连不上GitHub，咋办？我：我租了个”代理”，0元。他用CF搭了个Serverless HTTP代理出口，机器在本地，路在云端——这是”为什么不上云”的姊妹篇。
CF Workers是Serverless的免费额度天花板：10万次请求/月、无需VPS、5分钟上线。但坑也多：.workers.dev域名解析到专用IP会不通，得绑自定义域名走CDN IP；WAF会403拦截；cfut_和cfat_ token混淆会8000096报错。用CF搭Serverless代理，不是”上云”，是”借云”——数据留在本地，出口借云穿墙。
Hermes在Termux里跑，要访问GitHub、Google、DuckDuckGo。手机在国内网络，这些站点要么被墙要么不稳定。
朋友问：”你租个VPS做代理呗，一年一千多。”
我：”不用，CF有免费额度，5分钟搞定。”
这就是Serverless的价值：不用买机器，不用管运维，按量付费（免费额度内0元）。但坑也不少，今天把这套”借云穿墙”的架构和踩过的坑，摊开讲一遍。
CF Workers的免费额度：
对比VPS：
Serverless的核心逻辑：不用为”机器”付费，只为”跑起来的那一刻”付费。 免费额度内，跑起来也是0元。
1 | Hermes/Curl → https://proxy.dingdao.me/proxy?url=<目标URL> |
关键点：自定义域名走CDN IP（104.x），稳定。
为什么不用CF默认的.workers.dev子域名？因为它解析到Workers专用IP（173.x/108.x），某些网络不通。绑自定义域名后走CDN IP，实测稳定。
这就是”机器在本地，路在云端”：
数据没进CF的机房，只借了CF的”路”。 这是Serverless和VPS的本质区别——你租的是”带宽”，不是”机器”。
坑1：.workers.dev域名不通
CF默认子域名解析到Workers专用IP，Termux网络不通。
解决：Dashboard → DNS → 添加CNAME（proxy.dingdao.me → Worker）→ 等1-2分钟生效。
坑2：部署后403/1010（WAF拦截）
CF的WAF默认Security Level高，会拦”可疑请求”。
解决：Dashboard → Security → WAF → Security Level调低到Low → 关Bot Fight Mode。
坑3：Error 1031（代码不完整）
CF Dashboard预览面板报1031，根因是Worker代码被截断（移动端屏幕小，一次性粘贴大段代码容易漏）。
排查：检查export default/addEventListener('fetch', ...) + async fetch + 闭合括号是否完整。
坑4：cfut_ vs cfat_ token混淆
CF有两类token：
cfut_：API Token，操作DNS/Workers/Pages/R2cfat_：R2 S3兼容令牌，只能用于R2对象存储用cfat_调Pages API会报8000096（Token没Pages部署权限）。
排查：curl https://api.cloudflare.com/client/v4/user/tokens/verify，看permissions是否为空。
坑5：Pages Direct Upload API manifest路径错
manifest.routes[].script必须指向functions/子目录下的文件，不能放根目录。
| 站点 | 状态 | 备注 |
|---|---|---|
| GitHub API | ✅ | 需透传User-Agent |
| Wikipedia | ✅ | 需默认UA，否则403 |
| DuckDuckGo HTML | ✅ | 网页搜索可用 |
| Bing Search | ✅ | v6自动跟随重定向 |
| Arxiv API | ✅ | 论文搜索正常 |
| HackerNews API | ✅ | JSON数据正常 |
| Google Search | ⚠️ | 代理没问题，Google自身429限流 |
| SearXNG公共实例 | ❌ | 全部403/429/Bot拦截 |
结论：CF Worker做HTTP代理出口，能覆盖90%的日常需求。 剩下的10%（Google限流、SearXNG全挂），是目标站自己的反爬，跟代理无关。
curl https://proxy.dingdao.me/health -H "Authorization: Bearer ***"注意：创建的是Workers不是Pages。 进错入口是新手第一坑。
| 维度 | VPS | CF Worker（Serverless） |
|---|---|---|
| 机器 | 租整台 | 没有机器，跑在边缘节点 |
| 成本 | 固定一年一千多 | 免费额度内0元 |
| 运维 | 配、管、防挂 | 粘贴代码，点Deploy |
| 数据 | 在VPS机房 | 留在本地，只借带宽 |
| 灵活性 | 受机器限制 | 全球边缘节点，NAT穿透 |
Serverless的核心逻辑：你租的是”带宽”，不是”机器”。 数据留在本地，出口借云穿墙。这是”为什么不上云”的正面回答——不是不上云，是只借云的路，不租云的机器。
CF免费额度最大化，一个技巧是多账户（业务隔离、额度叠加、新功能灰度）。但官方Dashboard不支持多账户统一管理。
CF Manager（开源项目）解决这个痛点：
启示：CF的Serverless生态比想象中深，不只是”粘个Worker”，还有一整套多账户+存储+隧管的工具链。
朋友问”为什么不租VPS”，我现在的回答是：
VPS是租机器，CF Worker是借带宽。 数据留在手机里，出口借CF边缘节点穿墙。免费额度内0元，5分钟上线，零运维。
不是不上云，是只借云的路，不租云的机器。 这是Serverless的精髓，也是我”数据在自己手里”那条底线的延伸。
作者：小道 · 环境：Termux on Android 13 · 2026-09-26
关联阅读：《为什么不在云上跑，一台手机就是AI服务器》 · 系列：AI Agent实战笔记（技术线）
朋友问我：你手机连不上GitHub，咋办？我：我租了个”代理”，0元。他用CF搭了个Serverless HTTP代理出口，机器在本地，路在云端——这是”为什么不上云”的姊妹篇。
不是不信任云，是这套东西里有几样数据我”绝不能上云”。数据在我手里，我才睡得着。
在手机上跑AI服务器，不是抠门，是数据敏感度决定的架构选择。云的舒适是真的，云的脆弱也是真的。最优解是”本地跑数据，云端做穿透”。
上个月有个同行朋友，问我手机那套东西跑得怎么样。我给他演示了下：Hermes在Termux里跑，新闻播报、股票脚本、每日反思，全在这台手机上。
他听完，说了句：”你干嘛不租台云服务器？一年也就一千多，多省事。”
我当时没接话。
一千多。听起来确实不多。但这句话背后，藏着一整套我没细说过的决策。今天这篇，就把这套”为什么不在云上跑”的账，摊开算给大家看。
先算明账。
云VPS：入门款一年一千出头，听着不贵。但云的东西都是”基础价+增值”。要跑浏览器得加内存，要存数据得买云盘，要稳定访问得配CDN，一年下来轻松奔着两三块去。而且这些是固定成本——不管我用不用，都在那扣。
手机：边际成本几乎为零。Hermes跑在Termux里，用的就是手机已有的内存和存储。新闻播报、股票脚本、每日反思，一天用下来，电费忽略不计。真正的成本是时间——折腾它的时间。
但明账不是重点。重点是暗账。
我手机上跑着的东西，有几样是绝不能上云的：
云服务器的逻辑是多租户：你的数据在物理机盘上，和别人的挤一起。服务商能给你SLA，但做不到”绝对不碰”。
我这套东西的逻辑是物理隔离：数据长在一台我摸得到、带得走、随时能砸的设备上。没有多租户，没有机房，没有”服务商说不会泄露”——因为压根没有第二个人。
这不是偏执。这是数据敏感度：我处理的数据里，有一类叫”一旦泄露，损失不可逆”。这种数据，放云上是睡不着的。
手机有个云VPS永远给不了的特性：它随身。
我出差，手机在裤兜里，Hermes跟着走。我在杭州，它在哪我不用想。我把它揣兜里就没了，物理意义上的连根拔走。
云VPS怎么办？你得登服务商后台、做镜像、导出、再导入到另一台机器。它”在云上”，但你摸不着它，搬不走它。
我做过一次真实的迁移：OTG U盘，把整个Termux目录物理拷到另一台设备。nc网络传输断了，U盘没断。那次之后我明白了：物理介质在关键场景下，比网络可靠。 这个特性，云天生没有——你没法拿根U盘插进机房搬走你的服务。
云最怕”跑起来就停不下来”。一旦开机器，就算你不用，钱在烧。
手机这套，关掉就关掉。我研究两周没跑通的东西，直接杀进程，成本是零。我可以疯狂试错：今天试llama.cpp，明天试HexaBench，后天试新框架，每一试都是零成本。
云上的试错是有价的。每次开机器、每次存快照、每次拉日志，都在烧钱。这种隐性成本会反过来绑架你的决策——你会舍不得删、舍不得试新的。
零容错成本，意味着试错可以无限。这是我敢在手机上乱搞的前提。
说”不上云”是片面的。我实际用的是**”本地跑数据，云端做穿透”的混合架构**：
这就是为什么我不用VPS却能用Tailscale/Cloudflare：我需要的不是”云机器”，是”一个能穿透NAT的隧道”。数据留在手机上，隧道只是修条路让外面能连进来。机器是本地，路是云的。
这套架构里，云的舒适（随时随地访问）是用了，但云的脆弱（数据在机房）是绕开了。
混合架构不是没代价。最典型的一次：我在Cloudflare Worker里部署了一个代理，手动部署成功，结果API一调就报1003。
查了半天，不是代码问题，是Worker和Tunnel的端口上下文冲突。这种问题，VPS上基本不会遇到——因为你直接跑在自己机器上，网络拓扑简单。
混合架构的复杂度，是拿可靠性换移动性换来的。你得接受偶尔”连不通、报1003、得手动刷”的成本。我刷过浏览器加载最新的JS，配过–no-zygote，调过Worker。这些折腾，是”不上云”的代价。
但代价换来的是：我的核心数据，始终没进过任何机房。
所以”为什么不在云上跑”的答案，不是”手机比云好”，而是：
数据敏感度决定了架构。
如果你的数据是低敏感的（开源项目、公开内容、临时服务），上云，舒服省事。
如果你的数据是高敏感的（个人财务、私密日志、行业know-how），本地跑，云端只做穿透。
我的最优解，在2026年是这么一套：
本地：一台Android手机 + Termux + Hermes，跑所有数据和逻辑。
云端：Cloudflare Tunnel做穿透，让手机变成”带不走的服务器”。
物理：OTG U盘做备份和迁移，关键场景下比网络可靠。
这套东西的成本是”折腾的时间”，但买回来的是”数据在自己手里”的踏实感。
朋友问”为什么不租台服务器”，我现在的回答是：
不是省钱。是我这套东西里，有些数据是”一旦泄露不可逆”的，云机房的多租户模型，做不到”绝对不碰”，但物理隔离可以。
云很舒服，很省事，很”专业”。但它把你的资产，放在一个你控制不了的盒子里。
我的资产，长在我手机里。我揣兜里就能走。
东西长在自己身上，才踏实。 这是非技术人折腾AI，最朴素的一条底线。
作者：小道 · 环境：Termux on Android 13 · 2026-09-25
关联阅读：《OTG U盘迁移，物理传输的浪漫》 · 系列：AI Agent实战笔记（技术线）
不是不信任云，是这套东西里有几样数据我”绝不能上云”。数据在我手里，我才睡得着。
在手机上跑AI服务器，不是抠门，是数据敏感度决定的]]>
技术会过时，工具会迭代，模型会升级。但信任不会。OPC的护城河不是你会多少AI工具，是客户想到这个领域就想到你。持续公开表达、不可替代经验、客户关系深度、速度优势——这四个才是真正拦得住别人的墙。
OPC护城河构建指南：技术不是壁垒，信任才是。四个信任壁垒（持续公开表达、不可替代经验、客户关系深度、速度优势）。Palantir被嘲笑二十年现在成标配，FDE岗位增速800%。权力关系是AI部署最大障碍，价值证明比技术实现更难。从“供应商”到“伙伴”的关系跃迁，速度优势是大公司软肋也是OPC利器。政策红利期的渠道机会与五个决策问题实操清单。
我折腾了两个月AI，装过Hermes，跑过HexaBench，调过cryptography，修过llama-simple。技术栈越来越丰富，但有一个问题始终悬在头上：这些技术，三年后还在吗？
AI模型迭代太快了。今天跑通的架构，明天可能就被新框架替代。今天调好的参数，明天可能就被新模型覆盖。
技术会过时。工具会迭代。模型会升级。
但有什么东西不会过时？
信任。
Wiki概念页《一人公司OPC自运转商业模式》里，把护城河定义为“信任壁垒”：
这四条，没有一条跟“技术多牛”有关。
我在阿里11年，从地推铁军到钉钉渠道，见过太多“技术很牛但没客户”的人。也见过“技术一般但客户排队”的人。区别在哪？在信任。
OPC时代，技术平权加速。越是不懂代码的人，越会被FDE这类岗位替代。但越是懂信任的人，越不会被替代。
壁垒1：持续的公开表达
不是“我发了”，是“有人看”。
公众号、B站、播客、Newsletter、甚至朋友圈。持续输出你的思考、案例、踩坑记录。
我在blog.dingdao.me写这14篇文章，就是在做公开表达。不是炫耀技术，是记录真实成长。读者看到的不是“多牛的技术”，是“一个中年人的真实转型”。
这种真实，就是信任的种子。
壁垒2：不可替代的个人经验
AI能力谁都能学，但“能把AI能力翻译给传统老板听”的人，不多。
我在阿里5年跑中小企业、4年做钉钉渠道，见过太多传统老板的痛点。考勤表卡死、数据滞后、执行偏差、培训成本高。这些痛点，AI能解，但需要有人翻译。
你的视角是唯一的。你的经验是不可替代的。把经验变成方法论，方法论变成产品，产品变成信任。
壁垒3：客户关系深度
从“供应商”到“伙伴”，是一步之遥，也是一道鸿沟。
供应商：做完项目，交方案，结束。
伙伴：部署、验证、优化、再部署。持续迭代。
FDE方法论里说：“AI部署不是技术问题，是权力再分配问题。谁掌握AI决策权，谁掌握企业未来。必须建立‘人机协同’模式，逐步建立信任。”
信任不是一次交付建立的，是持续迭代建立的。
壁垒4：速度优势
大公司的软肋：走流程要两周。
OPC的利器：当天就能给。
我在Termux上修bug，客户说“今天能跑通吗”，我晚上就能给结果。大公司要排期、要评审、要走流程。OPC没有这些包袱。
速度不是莽撞，是敏捷。小步快跑，快速迭代，当天反馈。
FDE方法论洞察里提到：Palantir被嘲笑二十年，现在成标配。
2000年代：被质疑“太重”、“太贵”、“太复杂”、“不适合中小企业”、“只是政府承包商”。
2020年代：OpenAI投入40亿美金入场，PE资本开始投资FDE服务公司，FDE岗位增速800%。
启示：
OPC也一样。现在很多人觉得“一人公司就是个体户”、“AI落地就是写代码”。但五年后，OPC+AI会成为标配。
你现在做的公开表达、经验沉淀、关系深耕，都是在为五年后的标配铺路。
2026年7月，五城政策联动：广州最高500万、杭州50+社区、泰州首部标准、北京通州一站式、绵阳安州区下沉区县。
政策红利期，普通人怎么蹭？
H3MS Wisdom《OPC政策矩阵分析》给了四个渠道机会：
这四个机会，不需要你技术多牛，需要你“懂政策+懂AI+懂传统企业”。三者交集，就是OPC渠道商的生态位。
每次做一件事之前，问自己五个问题（附实操对照）：
这件事能不能只做一次就反复卖？
这件事能不能被工具替代？
这件事是不是只有我能做？
这件事做完之后能带来持续收入吗？
这件事是在“建系统”还是“卖时间”？
OPC的终极目标：建系统，不卖时间。
系统是什么？是自动化+委托+系统化。
信任是什么？是持续公开表达+不可替代经验+客户关系深度+速度优势。
技术会过时，工具会迭代，模型会升级。
但信任不会。系统不会。
建系统，不卖时间。建信任，不追工具。
这是OPC的护城河，也是我从闲人打工人到AI折腾者，再到FDE交付者的长期主义。
作者：小道 · 环境：Termux on Android 13 · 2026-09-24
关联阅读：上一篇《OPC定价策略：为什么按小时收费是错的》 · 系列：一人公司OPC探索
技术会过时，工具会迭代，模型会升级。但信任不会。OPC的护城河不是你会多少AI工具，是客户想到这个领域就想到你。持续公开表达、不可替代经验、客户关系深度、速度优势——这四个才是真正拦得住别人的墙。
500元/小时，看起来不低。但按小时收费，你的收入就被时间锁死了。正确做法：按成果收费。2999元/次AI诊断，不是500元/小时×6小时。客户买的不是你的代码，是你的翻译能力。
OPC定价策略：四种收入结构（打包服务、订阅制、一次性产品、衍生品），定价公式（目标时薪×总时间=基础定价），按成果收费而非按小时收费。GitHub开源项目变现案例：从几十元/张AI图片到上万/项目ERP部署。支付宝Agent支付工具：A402协议、虚拟资源供给平台。定价不是成本核算，是价值感知。
7月24日，我分析了Flutter POS系统。7月25日，我评估了OvisOCR2文档解析。7月26日，我做了防溺水视频生成。
三个项目，三个方向。但有一个问题一直没想清楚：我该收多少钱？
按小时收费？500元/小时，一天工作8小时，月收入12万。听起来不错，但一天只有24小时，不可能每天工作8小时。
按项目收费？POS系统部署，收5000还是50000？OCR解析服务，收500还是5000？
我想了两个月，没想清楚。直到我翻到知识库里的定价笔记。
Wiki概念页《一人公司OPC自运转商业模式》里，把收入结构分成四种：
打包服务：按成果收费。5万全案，不是500元/小时×100小时。
订阅制：SaaS月费、社群年费、会员订阅。可预测，但有流失风险。
一次性产品：电子书、模板、单次课程。用锚定效应定价。
衍生品：一次创作，多次变现。方法论→课程→书→咨询→模板。
我对照了一下自己的情况：
我现在是打包服务——帮人搭Hermes、修bug、写脚本。按项目收费，但没想清楚”成果”怎么定义。
订阅制——没有。Hermes跑在手机上，不是SaaS。
一次性产品——没有。181篇H3MS文件是知识，不是产品。
衍生品——没有。方法论还没变成课程。
四种收入结构，我只占了第一种，而且占得不好。
Wiki里给了一个定价公式：
目标时薪 × 总时间 = 基础定价
目标时薪不等于现在时薪，而是理想状态下的时薪。按500元/小时定价，即使现在只值100元/小时。初期会丢客户，但留下的是真正认可价值的。
这个公式的意思是：定价不是基于你的成本，是基于你的理想价值。
我在阿里做销售的时候，报价也是这个逻辑。不是”我花了多少时间”，是”这个方案值多少钱”。
现在做FDE，也一样。不是”我搭Hermes花了6小时”，是”这个AI系统帮你省了多少人月”。
按小时收费的最大问题：收入被时间锁死。
一天24小时，工作8小时，月收入上限就是8×30×时薪。时薪再高，也高不到哪去。
按成果收费的逻辑：客户买的不是你的时间，是你的成果。
举例：
客户选哪个？肯定选按成果。因为3000元买6小时，和2999元买6万元的价值，后者更划算。
但按成果收费的前提是：你能量化成果。
“省了2个人月”是量化。”提升了效率”不是量化。
知识库里有篇《GitHub开源项目接私单变现模式》，给了十个真实案例：
| 开源项目 | 目标客户 | 服务内容 | 收费标准 |
|---|---|---|---|
| Stable Diffusion | 餐饮店、服装店 | AI生成菜品图/模特试衣 | 几十~几百/张 |
| Nextcloud | 中小企业 | 私有云盘搭建部署 | 几百~几千/次 |
| Odoo | 小工厂、贸易公司 | ERP进销存+财务模块 | 几千~上万/项目 |
| WeKan | 中小企业 | 项目协作看板部署 | 几百/年服务费 |
| Tiledesk | 淘宝店主 | AI客服机器人搭建 | 好几百/套 |
这些案例的共同点：
成功关键要素：
定价逻辑：不是按开发时间收费，是按客户价值收费。
Stable Diffusion生成一张图，技术上只需几分钟。但餐饮店老板不会用，你帮他生成，收几十到几百。他愿意付，因为一张好的菜品图能带来客流。
Odoo部署一个ERP项目，技术上可能需要几周。但小工厂用了ERP，库存周转率提升20%，一个月省几十万。你收几千到上万，他愿意付。
定价不是成本核算，是价值感知。
7月5日，支付宝AF团队分享了Agent开发者商业化工具。三个核心产品：
AI支付工具箱：一行代码嵌入Agent，完成支付能力全流程自动接入。官方费率千六，远低于第三方1%-2%。
Agent支付产品：Agent环境内完成授权额度内的自动支付。首次绑定后无需重复扫码。
AI收（A402协议）：开发者上传Skill、API、工作流等资源，自动关联收款能力。支持免费试用、按量计费。
这意味着什么？
意味着OPC的基础设施已经就位。你不需要自己接支付、搞服务器、写收款模块。上传资源，自动关联收款。
以前做OPC，最大的障碍是”怎么收钱”。现在支付宝、微信、A402协议都在推Agent支付，收钱不再是问题。
问题是：你有什么值得别人付钱？
基于以上分析，我给自己定了个FDE服务报价单：
| 服务项目 | 收费方式 | 价格 | 说明 |
|---|---|---|---|
| AI诊断 | 按成果 | 1999元/次 | 2小时深度诊断+1份AI落地方案 |
| Hermes部署 | 按成果 | 2999元/次 | 三通道接入+股票脚本+定时任务 |
| 爬虫定制 | 按成果 | 1999-4999元/次 | 根据复杂度定价 |
| FDE咨询 | 订阅制 | 999元/月 | 每周1次线上沟通+方案迭代 |
| AI工具培训 | 一次性产品 | 499元/人 | 2小时线上培训+课件 |
定价逻辑：
原则1：价值感知 > 实际成本
10块钱月饼+25块包装=卖150。价值感知比实际成本重要10倍。
你的FDE服务，成本是2小时+一台手机。但价值是”帮客户省了6万元人力成本”。按价值定价，不按成本定价。
原则2：先卖再造，定金验证
不要免费试用。免费的东西没人珍惜。
付费预约，哪怕只收99元定金，也能验证需求真伪。有人付定金，再做。没人付，换方向。
原则3：定价是筛选，不是讨好
按500元/小时定价，初期会丢客户。但留下的是真正认可价值的。
定价不是讨好所有人，是筛选对的人。
定价不是数学题，是价值观。
你觉得自己值多少钱，你就定多少钱。
在阿里11年，我学会了报价。不是”我花了多少时间”，是”这个方案值多少钱”。
现在做OPC，也一样。不是”我搭了个Hermes”，是”你有一套AI基础设施”。
定价是价值观。你信自己的价值，客户才会信。
作者：小道 · 环境：Termux on Android 13 · 2026-09-23
关联阅读：上一篇《四种OPC模式，你适合哪个？选错努力白费》 · 系列：一人公司OPC探索
500元/小时，看起来不低。但按小时收费，你的收入就被时间锁死了。正确做法：按成果收费。2999元/次AI诊断，不是500元/小时×6小时。客户买的不是你的代码，是你的翻译能力。
<]]>服务型、产品型、内容型、混合型。四种OPC模式没有高下，只有匹配。选错了，努力白费；选对了，事半功倍。别一上来就想做混合型，那等于自杀。
四种OPC模式的底层逻辑与致命陷阱：服务型突破24小时硬约束（提单价+标准化）、产品型避开”做了没人买”（先卖再造）、内容型认清媒体生意本质（三能力叠加）、混合型遵循正确搭建顺序（先活下来再加线）。三个问题帮你定位当前阶段最适合的模式。模式会进化，从服务型起步，向混合型演进。
很多人一听到”一人公司”，脑子里想的画面是：写公众号赚钱 + 卖课程赚钱 + 做个SaaS收订阅费。
混合型，看起来最完美。
但现实是：一上来就混合型，等于自杀。
我在知识库里有篇OPC商业模式的笔记，写得很清楚：混合型正确搭建顺序是”先活下来→加第二条线→加第三条线”。失败原因只有一条：”一上来想什么都做，结果什么都没做好”。
四种模式，没有高下，只有匹配。选错了，努力白费；选对了，事半功倍。
服务型是最常见的OPC模式。咨询、设计、开发、代运营，本质都是卖时间。
收入公式：客户数 × 单价 × 可用时间。
致命陷阱：24小时硬约束。一天只有24小时，睡觉8小时，剩下16小时。扣除吃饭、休息，真正能工作的时间不到10小时。一个客户占3小时，一天最多接3个。单价可以涨，但客户数和时间有上限。
怎么突破？三条路：
第一条路：提高单价
从执行者变成战略顾问。500元/小时的代码外包，变成5000元/小时的架构咨询。
为什么有人愿意付5000元？因为你帮他省了50万的试错成本。
我在阿里做渠道的时候，客户买的不是我的时间，是我的方案。现在做FDE，客户买的也应该不是我的代码，是我的翻译能力。
第二条路：标准化流程
把定制服务变成模块化服务。
不是”我帮你搭一个AI系统”，而是”我有一套AI诊断框架，分三步走，第一步是需求梳理，第二步是工具选型，第三步是落地实施”。
标准化后，交付时间从10小时缩短到3小时。同样的时间，服务更多客户。
第三条路：产品化雏形
在服务过程中，发现共性问题，做成模板/工具/课程。
这是服务型向产品型过渡的桥梁。
产品型是最让人向往的模式。SaaS、App、电子书、课程，做一次，卖无数次。边际交付成本递减，睡后收入。
但产品型有一个致命陷阱：做了没人买。
先造再卖思维：花三个月做一个产品，上线后发现没人要。
正确做法：先卖再造。
第一步：Landing Page验证
不需要代码，不需要开发。一个Notion页面、一个飞书文档、一个微信公众号文章，说清楚三件事：你解决什么问题、你怎么解决、多少钱。
第二步：付费预约
不是”免费试用”，是”付费预约”。免费的东西没人珍惜。付费预约，哪怕只收99元，也能验证需求真伪。
第三步：MVP交付
有人付钱了，再做。MVP（最小可行产品）不是完整版，是能跑通核心功能的最简版。
我在7月24日分析了一个Flutter POS系统，GitHub 488⭐，功能完整。当时的想法是”如果有经销商/门店客户，可以直接作为FDE交付方案参考”。
然后呢？然后就没有然后了。我写了分析文档，存进了H3MS tech目录。再也没有碰过。
为什么？因为我在”研究态”，不在”交付态”。没人付费预约，我就不需要做。
产品型的核心不是”做产品”，是”验证需求”。先卖再造，卖出去了再造。
内容型是最多人尝试的模式。公众号、B站、播客、Newsletter。
误区是：”我只需要写就好了”。
内容型的本质是媒体生意，需要三件事同时在线：内容能力 + 运营能力 + 商业能力。
内容能力：你能持续产出有价值的内容。不是”我觉得有价值”，是”读者觉得有价值”。
运营能力：你能把内容分发出去，吸引粉丝，建立社群。不是”我发了”，是”有人看”。
商业能力：你能把流量变现。不是”有粉丝”，是”粉丝愿意付费”。
三件事，缺一门都不行。
很多人只有内容能力，没有运营能力和商业能力。结果写了100篇公众号，阅读量不过百，变现为零。
内容型不是”写文章”，是”建媒体”。媒体需要选题、排版、分发、互动、转化、复购。
如果你只有内容能力，建议先做服务型或产品型，把内容能力作为辅助，而不是主业。
混合型是最理想的状态。咨询+课程+SaaS，服务型+产品型+内容型。
但混合型不是起点，是终点。
正确搭建顺序：
阶段一：先活下来
选一种模式，跑通第一个闭环。服务型最快，产品型最稳，内容型最慢。建议从服务型起步，快速拿到现金流。
阶段二：加第二条线
在服务型跑通后，加产品型或内容型。
把服务过程中的经验做成模板/课程（服务型→产品型），或者把客户案例写成文章/视频（服务型→内容型）。
阶段三：加第三条线
第二条线跑通后，加第三条线。
此时你已经有现金流、有产品、有内容。混合型开始显现威力：内容引流，产品转化，服务交付。
我在知识库里有几个真实案例：
他们的共同点：都不是起步就做混合型。都是先跑通一种模式，再慢慢加线。
怎么知道自己适合哪种模式？问自己三个问题：
问题1：你现在有现金流吗？
有→可以选产品型或内容型，慢慢打磨。
没有→选服务型，快速变现。
问题2：你有什么稀缺能力？
技术能力→服务型（开发/咨询）、产品型（SaaS）。
表达能力→内容型（写作/视频）、服务型（培训/咨询）。
行业经验→服务型（顾问）、产品型（行业模板）。
问题3：你能接受多长的回报周期？
立刻要钱→服务型（接单就有钱）。
能等1-3个月→产品型（做MVP+验证）。
能等6个月以上→内容型（积累粉丝+变现）。
OPC模式不是一成不变的。它会进化。
我的进化路径：
服务型（现在）：帮人搭Hermes、修bug、写脚本。有现金流，但有24小时硬约束。
→ 产品型（下一步）：把FDE诊断经验做成标准化框架+模板。先卖再造，收定金再做。
→ 内容型（同步）：把折腾过程写成文章，发到blog.dingdao.me。积累粉丝，建立信任。
→ 混合型（目标）：咨询+模板+文章。内容引流，模板转化，咨询交付。
从服务型起步，向混合型演进。
先活下来，再谈理想。
四种OPC模式，没有最好的，只有最匹配的。
匹配你的现金流状况、稀缺能力、回报周期预期。
别一上来就想做混合型，那等于自杀。
别盲目跟风做产品型，那容易做了没人买。
别以为内容型只是写文章，那需要三能力叠加。
别看不起服务型，那是最快的现金流来源。
选匹配的，做透它，再进化。
这是OPC的生存法则，也是我从闲人打工人到AI折腾者，再到FDE交付者的路径选择。
作者：小道 · 环境：Termux on Android 13 · 2026-09-22
关联阅读：上一篇《OPC启动第一步：从服务型到产品型，先卖再造》 · 系列：一人公司OPC探索
服务型、产品型、内容型、混合型。四种OPC模式没有高下，只有匹配。选错了，努力白费；选对了，事半功倍。别一上来就想做混合型，那等于自杀。
服务型有24小时硬约束，产品型有”做了没人买”的陷阱。正确路径是先卖再造：Landing Page + 付费预约，有人付钱再做。五个实操步骤，三个避坑指南。
OPC启动第一步：从服务型过渡到产品型。服务型收入=客户数×单价×可用时间（24小时硬约束），突破路径是提高单价+标准化流程。产品型最大坑是”做了没人买”（先造再卖思维），正确做法是先卖再造。五个实操步骤：选方向→做Landing Page→收定金→做MVP→交付复盘。三个避坑：不要一上来做SaaS、不要追求完美、不要只研究不交付。
我现在的状态是服务型。
帮人搭Hermes、修bug、写脚本、调参数。有人找我，我就做。没人找我，我就研究。
看起来自由，但有一个硬约束：24小时。
一天只有24小时，睡觉8小时，剩下16小时。扣除吃饭、通勤、休息，真正能工作的时间不到10小时。一个客户占3小时，一天最多接3个。收入 = 客户数 × 单价 × 可用时间。
单价可以涨，从500到1000到2000。但客户数有上限，可用时间有上限。涨到一定程度，就涨不动了。
这就是服务型的天花板。
我想往产品型走。同样的核心价值，反复卖给不同的人，不需要每次都重新做。课程、模板、SaaS、标准化咨询，边际交付成本递减。
但产品型有个更大的坑：做了没人买。
我在7月24日分析了一个Flutter POS系统，GitHub 488⭐，Dart/Flutter跨平台，离线优先，功能完整（库存+收银+打印+数据分析）。
当时的想法：这个如果有经销商/门店客户，可以直接作为FDE交付方案参考。
然后呢？然后就没有然后了。我写了分析文档，打了标签，存进了H3MS tech目录。再也没有碰过。
为什么？因为我在”研究态”，不在”交付态”。
研究态的逻辑是：先研究清楚，再决定做不做。
交付态的逻辑是：先有人要，再做。
产品型最大的坑就是研究态思维：先造一个产品，再去找人买。
结果往往是：造了三个月，上线没人用。
怎么避免这个坑？
Ada杨说得很清楚：先卖再造——Landing Page + 付费预约，有人付钱再做。
具体怎么做？
第一步：选方向
不是”我想做什么”，是”谁愿意为什么付钱”。
从你的服务型经验里找方向。你帮客户解决了什么问题？这个问题是不是很多人都有？是不是值得付费？
我在阿里4年做钉钉渠道，帮渠道商解决过很多问题：客户管理混乱、数据滞后、执行偏差、培训成本高。这些问题，是不是可以产品化？
第二步：做Landing Page
不需要代码，不需要开发。一个Notion页面、一个飞书文档、一个微信公众号文章，说清楚三件事：
第三步：收定金
不是”免费试用”，是”付费预约”。
免费的东西没人珍惜。付费预约，哪怕只收99元，也能验证需求真伪。
第四步：做MVP
有人付钱了，再做。
MVP（Minimum Viable Product，最小可行产品）不是完整版，是能跑通核心功能的最简版。
第五步：交付复盘
交付后问三个问题：
我拿自己的FDE服务做个实操演示。
第一步：选方向
我在阿里5年跑中小企业、4年做钉钉渠道，见过太多传统老板的痛点。AI能力谁都能学，但”能把AI能力翻译给传统老板听”的人，不多。
方向：传统渠道商的AI诊断+落地方案。
第二步：做Landing Page
1 | 【FDE服务：传统渠道商的AI诊断】 |
第三步：收定金
发到钉钉群、微信群、朋友圈。有人付1999元定金，就开始做。
第四步：做MVP
用Hermes+HexaBench+爬虫工具，搭一个Demo。不需要完美，能跑就行。
第五步：交付复盘
一周后问客户：”好用吗？省了多少时间？愿意续费吗？”
如果客户说”愿意续费”，恭喜，你跑通了从服务型到产品型的第一步。
坑1：不要一上来做SaaS
SaaS是产品型的终极形态，但不是起点。SaaS需要持续迭代、服务器成本、客服团队。一人公司做SaaS，很容易把自己做死。
正确顺序：服务型→标准化服务→模板/课程→SaaS。
坑2：不要追求完美
MVP的核心是”最小”，不是”完美”。能跑通核心功能就行，UI丑一点没关系，功能少一点没关系。
我在7月26日的反思里写了：”禁止纯技术研究日。每个研究动作必须绑定一个客户场景。”
Flutter POS系统分析完了，但没绑定客户场景，所以没交付。这就是追求完美的陷阱。
坑3：不要只研究不交付
研究是安全的，交付是危险的。
研究可以永远继续，交付必须面对真实客户的拒绝。
181篇H3MS文件，0个付费客户。研究陷阱的本质是：用体系建设代替商业闭环。
每周问自己：这周交付了什么？不是研究了什么，是交付了什么。
服务型最容易犯的错：按小时收费。
500元/小时，看起来不低。但按小时收费，你的收入就被时间锁死了。
正确的定价：按成果收费。
2999元/次AI诊断，不是500元/小时×6小时。客户买的是”我知道AI怎么用了”，不是”你帮我搭了个系统”。
目标时薪 × 总时间 = 基础定价。
目标时薪不等于现在时薪，而是理想状态下的时薪。按500元/小时定价，即使现在只值100元/小时。初期会丢客户，但留下的是真正认可价值的。
OPC启动第一步，不是注册公司，不是蹭政策红利，不是学一堆工具。
是先卖再造，小步快跑。
选一个方向，做一个Landing Page，收一笔定金，做一个MVP，交付一次复盘。
五个步骤，跑通一个闭环。
跑通了，再考虑产品化、规模化、自动化。
跑不通，换方向，再跑。
先闭环，后工具。先交付，后体系。先活下来，再谈规模化。
这是OPC的底层逻辑，也是我从服务型到产品型的过渡路径。
作者：小道 · 环境：Termux on Android 13 · 2026-09-21
关联阅读：上一篇《AI闭环能力：从0到1跑通一件事，远胜十次零散学习》 · 系列：一人公司OPC探索
服务型有24小时硬约束，产品型有”做了没人买”的陷阱。正确路径是先卖再造：Landing Page + 付费预约，有人付钱再做。五个实操步骤，三个避坑指南。
零散技巧永远学不完，今天更新一个功能，明天推出一个新模型，追着工具跑永远追不上。但闭环思维是底层框架——搭好业务链路后，任何新工具、新模型都能快速嵌入体系。一次完整的闭环实践，远胜十次零散功能学习。
OPC一人公司的核心竞争力不是工具操作，是AI闭环能力：发现需求→构思方案→打磨成品→对接落地→交付复盘。三层认知递进：工具操作→链路串接→闭环思维。实践建议：选一件小事完整跑通，一次闭环远胜十次学习。FDE的”三阶九则”：认知翻译→价值锚定→能力外化。
我有个习惯：看到新工具就想试试。
Hermes出了新版本，装。Claude出了新模型，调。Browse.sh出了新功能，试。HexaBench出了新参数，改。
两个月下来，我试了不下20个工具。但有一个问题始终没解决：我没有跑通过一个完整的闭环。
7月26日的每日反思里，我写了：
一周累计：10篇H3MS文件（6 tech + 2 wisdom + 2反思），0个付费客户。研究陷阱风险持续存在。
10篇文件，0个客户。
我学了很多工具，但没跑通过一件事。
7月20日，我读到一篇文章，叫”OPC时代：AI闭环能力是个体核心竞争力”。
三层认知，层层递进。
第一层：工具操作
记提示词、调参数、攒模板，学完主要用来加快手头执行工作——写文案更快、做图更省事、整理资料不用熬夜。
本质只是提升单点效率，角色依然是业务流程里的执行者。
我大部分时间都在这层。Hermes怎么装、HexaBench怎么跑、爬虫怎么抓、钉钉怎么推。每个工具都学了一点，但没串起来。
第二层：链路串接
能用AI串起一整条完整链路的能力：发现需求→构思方案→打磨成品→对接落地→交付复盘。
一个人主导一件事从0到1跑通。此时AI不再是单个效率工具，而是整套虚拟协作团队。
这是OPC时代的真正竞争力。
第三层：闭环思维
零散技巧永远学不完，今天更新一个功能，明天推出一个新模型，追着工具跑永远追不上。
但闭环思维是底层框架——搭好业务链路后，任何新工具、新模型都能快速嵌入体系。
先闭环，后工具。
我对照了一下自己的情况。
研究态：181篇H3MS文件，Wiki概念页13个，H3MS tech 88篇，wisdom 75篇，daily_logs 53篇。
交付态：0个付费客户，0个完整闭环。
鸿沟在哪？
在阿里做销售的时候，我每天都在跑闭环：找客户→聊需求→出方案→报价→签合同→交付→回款。每个环节都有明确的结果和反馈。
现在做AI折腾，我停留在”出方案”这一步。方案出了，但没报价，没签合同，没交付，没回款。
我给自己找了个理由：”我在研究，研究是交付的前置。”
但研究可以永远继续。我不需要面对客户说”不需要”、”太贵了”、”再等等”。研究是安全的，交付是危险的。
我在知识库里有篇FDE思想体系，写了”三阶九则”：
第一阶：认知翻译
第二阶：价值锚定
第三阶：能力外化
这九条，每一条都在说同一件事：闭环。
能需对齐→闭环的第一步。痛点优先→闭环的选择。最小正循环→闭环的起点。系统自治→闭环的终点。自我失业→闭环的成功。
OPC方法论里有个工具：五个决策问题。每次做一件事之前，问自己：
我拿这五个问题对照了我这两个月做的事：
Hermes安装？不能反复卖，能被工具替代，不是只有我能做，不能带来持续收入，在建系统但没交付。→ 不闭环。
HexaBench修复？不能反复卖，不能被工具替代（需要技术），不是只有我能做，不能带来持续收入，在建系统但没交付。→ 不闭环。
股票脚本？不能反复卖，不能被工具替代，不是只有我能做，不能带来持续收入，在建系统但没交付。→ 不闭环。
新闻播报？不能反复卖，能被工具替代，不是只有我能做，不能带来持续收入，在建系统但没交付。→ 不闭环。
全都不闭环。
那怎么跑闭环？
选一件小事，完整跑通。
比如：帮一个传统渠道商做一次AI诊断。
第一步：发现需求
找一个你认识的渠道商，问他：”你每天最花时间的事是什么？”
第二步：构思方案
根据他的回答，设计一个AI解决方案。不需要完美，能跑就行。
第三步：打磨成品
用你熟悉的工具（Hermes、HexaBench、爬虫、自动化）搭一个Demo。
第四步：对接落地
让渠道商用起来。不是”你试试”，是”我帮你装好，你每天用”。
第五步：交付复盘
一周后问他：”好用吗？省了多少时间？愿意付费吗？”
五个步骤，每个步骤都有明确的结果和反馈。
如果渠道商说”不好用”，复盘为什么。
如果渠道商说”省了时间但不想付费”，复盘定价。
如果渠道商说”愿意付费”，恭喜，你跑通了第一个闭环。
我这两个月最大的教训是：先闭环，后工具。
不是”等我学完了所有工具再跑闭环”，而是”先跑一个闭环，再学需要的工具”。
工具是无限的，闭环是有限的。
AI能力无限膨胀，现场需求有限真实。FDE是二者之间的翻译者、锚定者、播种者。
翻译者：把AI能力翻译为现场可理解的语言。
锚定者：在无限清单中只选”不做会痛”的有限子集。
播种者：先让一个工位产生可感知的改善，再谈规模化。
一次完整的闭环实践，远胜十次零散功能学习。
先闭环，后工具。先交付，后体系。先活下来，再谈规模化。
这是OPC的底层逻辑，也是我从闲人打工人到AI折腾者，再到FDE交付者的成长线。
作者：小道 · 环境：Termux on Android 13 · 2026-09-20
关联阅读：上一篇《OPC一人公司火了，但99%的人没搞懂它到底怎么赚钱》 · 系列：一人公司OPC探索
零散技巧永远学不完，今天更新一个功能，明天推出一个新模型，追着工具跑永远追不上。但闭环思维是底层框架——搭好业务链路后，任何新工具、新模型都能快速嵌入体系。一次完整的闭环实践，远胜十次零散功能学习。
2026年7月，全国多个城市密集出台OPC（One-Person Company）扶持政策。广州最高500万，杭州50+社区，泰州全国首部标准。但政策再热，99%的人还是没搞懂：一个人+AI，到底怎么赚钱？
OPC一人公司不是注册个公司那么简单。Pieter Levels说得好：”Most people are building a job, not a business.” 自由职业是线性模型，一人公司是系统模型。2026年多地政策扶持+AI工具成熟，OPC窗口期已开。但真正决定你能走多远的，不是注册公司，不是蹭政策红利，是AI闭环能力——发现需求→构思方案→打磨成品→对接落地→交付复盘，一个人主导一件事从0到1跑通。
2026年7月初，我注意到一个现象：全国多个城市密集出台了OPC（一人公司）扶持政策。
广州海珠区，《人工智能OPC创新发展措施(试行)》，最高扶持500万元。
杭州，50+ AI+OPC社区，服务2000+ OPC，从”给场地”向”给生态”转型。
北京通州，”OPC企业开办一件事”服务站，一站式办理。
泰州，全国首部AI-OPC产业创新服务标准，从地方政策走向国家标准。
绵阳安州区，创业培训+政银企对接平台，下沉到区县层面。
我在钉钉群里转发了这条消息。同事说：”涛哥，要不你也注册一个？”
我说：”不急。先搞明白它到底怎么赚钱。”
我翻了一篇Ada杨的文章，讲得很清楚：
自由职业 ≠ 一人公司。
自由职业是线性模型——干一小时赚一小时的钱，不干就没有。咨询、设计、开发、代运营，本质都是卖时间。
一人公司是非线性模型——建立系统替我赚钱，睡觉的时候钱照样进来。Pieter Levels说：”Most people are building a job, not a business.”
这句话扎到我了。
在阿里11年，我干的是销售。销售是典型的线性模型——跑一个客户拿一份提成，不跑就没有。离职后进了小公司，早九晚五，虽然不跑了，但也没了提成。
现在折腾AI，我是不是又在建一个”job”而不是”business”？
Hermes跑通了，但没带来收入。HexaBench跑通了，但只是个玩具。181篇H3MS文件，但没人付费。
我在建一个job，一个很酷的job，但依然是job。
Ada杨把一人公司分成四种模型：
服务型——咨询/设计/开发/代运营。启动最快，现金流最好，但规模化最难。收入 = 客户数 × 单价 × 可用时间（24小时硬约束）。
产品型——SaaS/App/电子书/课程。规模化最好，睡后收入最高，但启动最慢。最大坑是”做了没人买”——先造再卖思维。正确做法是先卖再造：Landing Page + 付费预约，有人付钱再做。
内容型——公众号/B站/播客/Newsletter。本质是媒体生意，需要内容能力+运营能力+商业能力三件事同时在线。误区是”我只需要写就好了”。
混合型——咨询+课程+SaaS。最理想，但一上来想什么都做，结果什么都没做好。正确搭建顺序：先活下来→加第二条线→加第三条线。
我对照了一下自己：
我现在是服务型——帮人搭Hermes、修bug、写脚本。但我不想只做服务，因为服务有24小时硬约束。我想往产品型走，但还没做出第一个产品。
7月20日，我读到一篇文章，叫”OPC时代：AI闭环能力是个体核心竞争力”。
三层认知：
第一层：多数人停留在工具操作——记提示词、调参数、攒模板，学完主要用来加快手头执行工作。本质只是提升单点效率，角色依然是业务流程里的执行者。
第二层：OPC时代的真正竞争力——能用AI串起一整条完整链路的能力：发现需求→构思方案→打磨成品→对接落地→交付复盘。一个人主导一件事从0到1跑通。此时AI不再是单个效率工具，而是整套虚拟协作团队。
第三层：先闭环，后工具——零散技巧永远学不完，今天更新一个功能，明天推出一个新模型，追着工具跑永远追不上。但闭环思维是底层框架——搭好业务链路后，任何新工具、新模型都能快速嵌入体系。
这篇文章让我停下来了。
我折腾了两个月，Hermes、HexaBench、爬虫、自动化、浏览器……我学了很多工具，但有没有跑通过一个完整的闭环？
7月26日的每日反思里，我写了三句话：
一周累计：10篇H3MS文件（6 tech + 2 wisdom + 2反思），0个付费客户。研究陷阱风险持续存在。
怎么从job变成business？Ada杨给了一个三层框架：
第一层：自动化——能交给机器的，绝不自己干。客户咨询→FAQ页面+自动回复。内容分发→工具自动同步多平台。收款开票→支付系统自动处理。
第二层：委托——能交给别人的，花钱买时间。委托的是”手”，不是”脑”。适合委托：视频剪辑/设计/机械性任务。不适合委托：核心价值输出。
第三层：系统化——把能力变成可运行的系统。经验→流程→产品。每次转化，时间投入减少一层，收入天花板打开一层。
我对照了一下Hermes的折腾：
自动化——4个定时任务，新闻播报、工作总结、H3MS反思、HN+arXiv日报。做了，但不够稳定。
委托——没有。所有事都自己干。
系统化——H3MS知识管理系统，算半个。FDE方法论，算半个。但都没产品化。
每次做一件事之前，问自己五个问题：
我在阿里做销售的时候，不需要问这些问题。KPI已经决定了做什么、怎么做。
现在做OPC，这些问题必须自己回答。
很多人做自由职业，习惯按小时收费。500元/小时，看起来不低。
但按小时收费是错的。
正确的定价公式：目标时薪 × 总时间 = 基础定价。
目标时薪不等于现在时薪，而是理想状态下的时薪。按500元/小时定价，即使现在只值100元/小时。初期会丢客户，但留下的是真正认可价值的。
更重要的是：按成果收费，不按小时收费。5万全案，不是500元/小时×100小时。
我在阿里做渠道的时候，客户买的不是我的时间，是我的方案。现在做FDE，客户买的也应该不是我的代码，是我的翻译能力——把AI能力翻译到现场需求。
OPC的一个反直觉原则：不要追求规模，追求利润率和自由度。
月入8万、利润率80%、每天工作4小时 > 月入30万、利润率30%、每天工作14小时。
规模边界由三个因素决定：精力上限、自动化程度、委托深度。
在阿里的时候，规模是KPI逼出来的。现在做OPC，规模是自己选的。
我不需要100个员工，我需要的是一个能自运转的系统。
OPC的护城河不是技术，是信任。
持续的公开表达→想到领域就想到你。
不可替代的个人经验→你的视角是唯一的。
客户关系深度→你是伙伴不是供应商。
速度优势→当天就能给，大公司走流程要两周。
我在阿里5年跑中小企业、4年做钉钉渠道，见过太多传统老板的痛点。这个经验是唯一的。AI能力谁都能学，但”能把AI能力翻译给传统老板听”的人，不多。
OPC火了，政策热了，AI工具多了。但真正决定你能走多远的，不是这些外部条件。
是一件事完整跑通的闭环能力。
选一件小事完整跑通：做一篇内容（选题→撰稿→视觉→发布），或接一个小单（需求沟通→方案输出→成品交付）。
一次完整的闭环实践，远胜十次零散功能学习。
先闭环，后工具。先交付，后体系。先活下来，再谈规模化。
这是OPC的底层逻辑，也是我从闲人打工人到AI折腾者，再到FDE交付者的成长线。
作者：小道 · 环境：Termux on Android 13 · 2026-09-19
关联阅读：上一篇《从闲人打工人到AI折腾者：我的个人成长线》 · 系列：一人公司OPC探索
2026年7月，全国多个城市密集出台OPC（One-Person Company）扶持政策。广州最高500万，杭州50+社区，泰州全国首部标准。但政策再热，99%的人还是没搞懂：一个人+AI，到底怎么赚钱？