第 35 节 · SECTION 35

AI 开发与资源层创业

我叫韩先凯，也叫离谱。很多人先通过英语学习认识我，后来读到我关于软件创业、失败、恢复与重新出发的记录。现在，我公开披露自己作为中国词元云计算有限公司董事长的身份，也把人生的下一段实践放在一个更具体的问题上：当 AI 变成基础能力，一个普通人如何从学习者走到建设者，再走到资源层的创业者？

这不是一篇“用 AI 轻松发财”的故事，也不是一份收益承诺。它是一张正在接受现实校验的工作地图：哪些事情已经发生，哪些方法可以复用，哪些商业结果还必须交给真实用户、真实成本、真实故障和真实时间回答。2022 年公司失败时，我已经亲眼见过“看起来像 AI”的功能如何掩盖数据、架构和责任问题；今天的门禁，正是从那次失败里长出来的。

本章的工程与商业原则，可通过客户验证、可持续经营、AI 工作流和可靠性评测进一步落到一次小实验。

先把事实、实践和结果分开

已经发生：我在中国词元云计算有限公司承担董事长职责；官网当前将 token.love 描述为面向企业与政企场景的统一 AI 智能网关，并列出模型接入、路由容灾、用量计量、审计留痕和私有化/离线部署能力。
正在实践：我使用 AI 学习新知识、拆解需求、开发项目、编写测试、整理文档和完成交付，也在把这些经验放回团队与企业场景中验证。
尚待验证：客户是否持续付费、服务能否规模化、单位经济能否成立、供应商变化是否可控，以及收入是否足以覆盖风险。

如果事实、判断和愿望混在一起，创业文章就会变成广告；把它们分开，才有可能成为复盘。准备拆解一段公开经历时，可以使用AI 经历案例复盘模板，先把来源和事实写清，再谈判断与迁移。

2022 年的失败如何改变今天的门禁

当年的问题不是没有写代码，而是没有先证明核心能力、数据集、性能、安全和用户价值。UI、多端适配和预设结果让产品看起来完整，却不能回答“数据从哪里来”“结果如何验证”“失败谁负责”。

因此，今天每个 AI 项目都先问五个问题：

能力真实存在吗：是模型、检索、规则还是人工流程，不能用营销词替代说明；
数据允许使用吗：来源、授权、敏感等级、留存和删除是否清楚；
结果如何验收：测试样本、边界条件、人工复核和真实用户标准是什么；
成本能否覆盖：模型、网络、工程、支持、返工、合规和故障成本是否进入账本；
失败如何退场：谁能暂停、降级、切换、通知、回滚并复盘。

如果五个问题没有答案，最小动作不是继续加功能，而是缩小问题并做一项能推翻假设的实验。

一、从学习者到建设者

我曾经把英语学习理解成“记住更多”，后来才知道，学习的终点不是收藏答案，而是能够独立完成任务。AI 学习也一样：真正有价值的结果，不是模型给出了多长的回答，而是我能否在关闭对话之后，解释关键决定、运行程序、面对错误、交付作品。

我现在使用一条工作闭环：

提出真实问题：写清谁遇到什么问题，以及什么结果才算完成；
留下无 AI 基线：先独立做一次，暴露知识缺口、约束和判断盲点；
准备可信材料：提供官方文档、数据、现有代码、组织政策和风险边界；
让 AI 帮我拆解：比较方案、生成小步实验、解释假设，不外包最终判断；
主动开发与验证：用 AI 辅助原型、编码、重构、测试、文档和调试；
接受多源反馈：测试、真实用户、领域专家、来源材料和安全审查共同判断；
保存状态与证据：记录完成、错误、成本、决策和下一项最小任务。

这条闭环与使用 AI 学习一切相连，但项目开发多了一条硬要求：每个关键决定都必须能够被测试、被解释，或被回滚。

二、用 AI 开发项目：速度之后仍然要有质量

AI 可以在几分钟内生成看起来完整的代码，也可以在几分钟内把错误扩散到整个项目。我的工作方式不是让 AI 代替开发者，而是让它成为一个高频、可质询、必须接受验收的协作者。

2.1 项目简报

每个项目先创建一页 task-brief.md：

# Task Brief

真实场景：
使用者/受众：
要完成的决策或动作：
截止时间：

已知事实与来源：
允许使用的文件：
数据敏感等级：公开 / 内部 / 机密 / 受限
明确不提供的材料：

最终交付物：
格式与长度：
验收标准：
必须由人确认的事项：

AI 可以做：
AI 不可以做：
人工审阅者：
失败时如何回滚或停止：

“体验好”“架构先进”“智能化程度高”不是验收标准。把标准写成可观察的动作，例如“用户能在 10 分钟内完成一次导入并看到错误报告”。

2.2 可复查的开发链

阶段	AI 可以协助	人必须确认
需求	整理用户、场景、限制和问题	问题是否真实，完成标准是否可观察
方案	提出架构、接口和最小实验	数据边界、依赖、失败模式和长期成本
原型	生成页面、接口、脚本和样例数据	是否解决核心任务，而不是只展示效果
实现	补全代码、解释改动、生成测试	关键逻辑、权限、异常处理和可维护性
校验	运行测试、静态检查、性能和安全检查	测试是否覆盖真实风险，结果能否复现
交付	整理文档、部署步骤、变更记录和回滚方案	用户能否使用，团队能否接手，问题能否追溯

每次只推进一个逻辑切片，不把需求、重构、格式化和依赖升级混在一起。保留一份无 AI 基线、一份真实可运行作品和一份错误/修订记录，才能区分速度与能力。

2.3 代码和发布门禁

这是任务简报和当前代码结构。先不要写代码。
提出两个最小实现方案，比较需求覆盖、改动范围、依赖、失败模式、测试难度、数据/权限风险和迁移成本。
明确缺失信息和推断。最后只推荐一个 1–2 小时可验证的切片。

发布前至少保存：版本号、变更摘要、迁移步骤、监控指标、回滚触发条件、负责人和用户通知。代码审查按严重性检查需求偏差、数据丢失、权限绕过、注入、竞态、异常处理、性能、可维护性和测试缺口。

每次试点或发布后填写AI 项目评分卡，同时保留无 AI 基线、AI 辅助版和延迟独立复测；没有这三份样本，就无法判断工具带来的是能力、代做还是返工。

三、什么是 AI 资源层

模型是能力层，应用是用户看见的结果；两者之间还需要一层让能力变得可接入、可控制、可计量、可持续运行的基础设施。我把这层称为 AI 资源层。

它不只是“卖一个模型接口”，而是把分散的模型、账号、算力、数据边界和组织流程，整理成团队可以理解、使用和治理的服务。

随着工具调用和智能体编排变得普遍，资源层还要处理互操作与授权边界。MCP 规范把资源、提示和工具定义为可组合的连接能力，但不会替系统完成安全审查；接入任何外部服务器前，仍需列出数据范围、写入权限、用户同意、调用记录和撤回路径。协议降低的是重复接入成本，不是责任成本。实践上可用 AI 工作流的授权门和 AI 评测的过程/结果记录先做小范围验证。

3.1 能力地图

资源层能力	客户遇到的问题	最小可验证证据
多模型接入与路由	业务押在单一供应商上，切换成本高	两种模型在同一任务上的路由规则和对比记录
身份、权限与配额	谁能使用、能用多少、出了问题无法追溯	角色矩阵、配额策略、审计日志样例
计量、成本与结算	能用但不知道团队和项目花了多少	按团队/项目/调用的成本报表和对账流程
部署与运行	服务无法进入组织批准的网络和环境	部署清单、环境差异、回滚演练记录
观测与故障处理	延迟、失败、质量波动无法解释	请求日志、错误分类、告警和处理记录
数据与合规边界	敏感数据流向、保留和人工审批不清楚	数据流图、保留规则、审批和删除证明
系统集成与支持	能力无法进入业务流程，出了问题找不到人	集成验收、值班表、支持工单和交接文档

对客户而言，价值不是“多一个模型名称”，而是少一些重复集成、少一些失控成本、少一些供应商切换中断，并多一层可被组织理解和管理的责任界面。

3.2 一次请求的生命周期

参考架构不是产品承诺，但每个资源层服务都应能解释一条请求如何流动：

身份认证 → 权限与配额 → 数据检查 → 路由决策 → 模型调用 → 结果过滤 → 计量记录 → 监控告警 → 用户交付

每一步都要回答：谁负责、记录什么、失败怎么办、数据保存多久、是否能够重放或删除。只做接口转发，却没有计量、权限、日志、降级和审计，无法成为可靠的企业服务。

3.3 路由不是“选最强模型”

路由策略应以任务和约束为中心：

低风险、高频、结构稳定的任务，优先考虑成本和延迟；
需要复杂推理或长上下文的任务，比较质量、上下文限制和失败率；
涉及敏感数据的任务，先看批准范围、部署位置和日志策略；
供应商异常时，执行降级、重试、切换或人工接管；
每次路由变化都记录版本、原因、样本和回滚方式。

“最强”如果不稳定、不可审计或成本不可承受，就不一定是最合适的模型。

四、中国词元云与 token.love：一条正在实践的业务路径

中国词元云计算有限公司是我当前承担董事长职责的公司。官网当前将 token.love 描述为面向企业与政企场景的统一 AI 智能网关，并列出模型接入、路由容灾、用量计量、审计留痕和私有化/离线部署能力。这是官网首页的产品定位，不代表任何第三方机构背书，也不替代正式文档、合规审批、合同与客户自己的安全审查。

从资源层看，这条业务路径可以拆成：

模型与算力资源 → 统一接入与路由 → 权限、计量与治理 → 企业系统集成 → 运行维护与持续服务

真正的产品要让客户知道：能力从哪里来，成本如何产生，数据经过哪里，发生故障谁来处理，下一次迁移是否仍然有选择。具体能力、可用地区、套餐、合规范围和服务承诺，应以 token.love 的正式说明和书面协议为准。

五、企业试点：先解决一个可验收的问题

5.1 发现阶段

第一次沟通不要先演示模型。先问：

现在的流程是什么，哪一步最慢或最容易出错；
谁承担这个成本，多久发生一次，错误会造成什么影响；
哪些数据可以使用，哪些数据绝不能离开组织边界；
客户已有账号、合同、网络、权限和安全要求是什么；
如果试点成功，谁会持续使用、审批和付费；
什么结果会让客户明确说“继续”，什么结果会让双方停止。

输出一页问题简报，不输出一页泛泛的 AI 价值宣言。

5.2 试点阶段

一个合格的试点应有：范围、样本、非目标、数据边界、负责人、时间、验收标准、失败退出条件和成本上限。试点前保存旧流程的基线：人工时间、错误率、等待时间、返工次数、现有成本和用户满意度。

试点期间同时记录新流程：模型调用、路由、延迟、失败、人工接管、支持工时、数据异常、返工和用户反馈。只记录“生成了多少内容”，无法证明业务改善。

用AI 项目评分卡按版本登记测试条件、成本、独立表现和上线门禁，避免试点结束后只剩一场演示。

5.3 验收与交接

交付前把验收拆成四层：

功能：流程能否完成，错误是否可见；
质量：输出是否达到业务标准，异常是否能人工接管；
安全：权限、日志、数据保留、删除和审计是否通过；
运营：谁负责升级、故障、成本、供应商切换和用户支持。

交接包应包含架构图、数据流图、权限矩阵、环境变量说明、部署步骤、监控面板、值班与升级路径、回滚方法、已知问题和下一次复盘日期。

六、赚钱逻辑：为客户承担可计价的工作

赚钱不是把模型名称换一层包装再加价，而是为客户承担一部分原本昂贵、分散或难以管理的工作。可能的价值交换包括：

资源管理服务：按调用、团队、项目或服务等级管理模型接入、配额和成本；
集成与交付服务：接入客户已有系统，完成部署、权限、日志和验收；
持续运行服务：处理升级、故障、质量波动、供应商切换和日常支持；
治理与安全服务：建立数据边界、审批、审计、留痕和风险处置流程；
定制项目与培训：围绕真实业务问题完成方案、原型、上线和团队交接。

这些不是收入承诺，而是可以逐项验证的收费接口。每项都必须回答：客户为什么愿意付费，结果如何验收，服务成本能否长期覆盖。

6.1 收费方式与适用场景

收费接口	适合解决	主要风险	必须记录
一次性诊断/方案费	帮客户明确流程、边界和试点	方案交付后没有后续价值	交付物、工时、后续转化信号
项目实施费	集成、部署、权限和验收	每个客户都重新定制，无法复制	范围、变更、返工和毛利空间
用量或资源管理费	按调用、项目或团队持续管理	供应商价格和用量波动	调用量、路由、成本、对账和上限
订阅/服务等级费	持续运营、支持和治理	服务承诺超过团队能力	响应时间、可用性、支持工时和例外
培训与顾问费	帮团队建立使用和治理能力	学完后不使用，效果难归因	课程目标、作业、迁移和复测

实际合同应以双方正式约定为准。公开文章只讨论商业逻辑，不虚构价格、利润、客户数量或收益结果。

6.2 成本账本

资源层创业容易只看需求，不看成本。至少记录：模型与算力、网络与存储、工程开发、客户支持、销售获客、合规与安全、故障补偿、供应商涨价、迁移、税费和管理时间。

贡献空间 = 客户收入
          - 模型与基础设施
          - 工程与支持
          - 获客与合规
          - 故障、返工与退款

每个项目分开记录一次性成本与持续成本。一次性项目看交付效率，持续服务看留存、支持强度、单位成本和续用信号。若每新增一个客户只新增调用费用、人工和风险，规模越大，亏损可能越快。

七、运维：没有运行手册就没有企业服务

7.1 最低监控面板

请求量、成功率、失败类型和重试次数；
延迟分布，而不是只看平均值；
按模型、团队、项目和任务的成本；
超配额、异常数据、权限拒绝和人工接管；
供应商状态、路由变化和版本变化；
用户反馈、支持工时和重复问题。

这些是建议的运营指标，不代表 token.love 当前已经提供全部能力。上线前应把指标、责任人、告警阈值和保存周期写进项目合同或内部运行手册。

7.2 故障分级与处理

发现 → 判断影响范围 → 暂停危险变更 → 降级/切换/人工接管
     → 通知受影响的人 → 保存日志与时间线 → 修复并验证
     → 复盘根因、成本和预防措施 → 更新运行手册

严重故障至少记录：发现时间、受影响项目、最近变更、数据风险、临时措施、供应商状态、恢复时间、客户沟通、根因假设和永久修复证据。AI 可以帮助整理时间线，但不能替代事故负责人。

7.3 供应商切换演练

每个关键供应商至少准备：备用路由、降级模型、限流策略、缓存或人工流程、数据迁移方案、合同联系人和回滚测试。每季度用一个低风险样本演练一次，验证“能切换”而不是把它写在文档里。

八、数据、安全与合规边界

数据级别	示例	默认做法
公开	已发布文档、公开代码和数据	可使用，检查来源和许可证
内部	未发布计划、流程、非敏感日志	只用组织批准工具，限制成员与留存周期
机密	客户资料、合同、商业策略、未公开漏洞	未明确批准不上传，优先本地处理或脱敏
受限	密钥、身份/医疗资料、儿童数据、第三方隐私	不进入通用模型，按组织政策和适用法律处理

资源层服务必须能够回答：数据从哪里进入、经过哪些供应商、哪些日志会保存、谁能查看、多久删除、如何证明删除。删除一个文件不等于删除所有历史、缓存、导出和备份。

九、十二周验证路线

时间	重点问题	行动	必须留下的证据
第 1–2 周	哪类组织有最急迫、具体的问题？	访谈、看旧流程、画数据流	访谈记录、基线、边界、停止条件
第 3–5 周	最小产品能否减少集成或管理成本？	建立沙盒、接入一个任务、跑对照测试	可运行原型、测试、失败记录、成本
第 6–8 周	客户是否愿意在真实流程中持续使用？	小范围试点、人工接管、每周复盘	使用轨迹、故障、支持工时、安全记录
第 9–10 周	交付是否能够被另一个人复制？	交接、部署和回滚演练	运行手册、权限表、交接验收
第 11–12 周	成本、质量和收费是否形成组合？	复盘、报价实验、续用讨论	成本账本、报价、续用信号、下一决策

证据不支持继续时，缩小问题、改变客户或停止方案；证据支持继续时，也要先补齐安全、合同、权限、监控与交接，再谈扩大。

十、公众号文章的两个实践切片：从“抽象”到“逐帧”

微信公众号里有两篇与我相关的文章，分别从人物观察和网络争议的角度写 AI。它们不是技术审计、客户案例或收入证明；我把它们当作公开叙事材料，借其中的动作和问题意识，补充这条实践路径。

10.1 拒绝第一个“最可能的答案”

2026 年 8 月 11 日，TokenMany 发布《韩先凯：AI 圈最“抽象”的人类》。文章把“抽象”解释为不急着接受现成答案，愿意让技术、商业、人性和日常生活互相照见。这是作者形象的文学化观察，不是对能力的独立测量。

我把其中可迁移的部分翻译成开发动作：

先写出默认假设，再列出至少一个相反解释；
把跨领域联想压缩成一个可在 1–2 小时内验证的小实验；
记录哪些观察来自事实，哪些只是类比、直觉或待验证假设；
允许实验推翻自己的漂亮想法，并把失败样本留在项目记录里。

这样，“脑洞”才不会停在表达风格上，而会经过问题定义、最小原型、测试和复盘，变成可以被别人检查的证据。

10.2 把喧嚣还原成可回应的问题

2026 年 8 月 21 日，观雪控股的 Wanli Center 发布《韩先凯与 AI：把喧嚣拆成一帧一帧的情绪》。文章以叙事方式写到：把评论逐条交给 AI 分类，旁边记录“观点、证据、情绪强度、表达方式、可回应程度”，并把“骂人的话”先当成“情绪样本”。这段文字不能证明已经交付了一个舆情产品，也不能证明分析改善了现实结果；它提供的是一个值得谨慎试验的反馈处理框架。

在真实项目里，我会把这个框架收敛成一条有边界的流程：

步骤	AI 可以协助	人必须负责
收集	去重、聚类、标记重复主题	确认来源、授权、最少必要数据和删除期限
拆分	区分事实陈述、推测、情绪词和表达策略	判断事实是否有证据，避免把标签当结论
排序	按影响、紧急度和可回应程度生成队列	确认优先级、风险和是否需要人工升级
回应	生成多个语气克制、指向具体问题的草稿	核对事实、隐私、责任与公开范围
复盘	汇总变化、重复误解和未解决问题	决定是否改产品、补说明、暂停回应或停止实验

评论、工单和客户反馈都可能含有个人信息。未经授权，不应把整段对话、姓名、联系方式或可识别细节直接上传到通用模型；即使数据公开，也要先脱敏、限制访问并设定保存期限。AI 能帮助把噪声排成队列，却不能替人判断谁对谁错，更不能替人承担公开回应的责任。

这两篇文章给我的共同提醒是：创造力负责提出不同的入口，证据负责决定是否继续；情绪值得被看见，但必须经过事实、隐私和责任的过滤，才能进入产品与企业流程。

十一、最容易失控的地方

把模型输出当事实，把演示效果当产品质量；
把一次性项目收入误认为可持续业务；
只计算 API 成本，不计算支持、返工、合规、销售和管理时间；
把客户数据、公司机密或第三方隐私上传给未经批准的工具；
被单一模型或供应商锁定，却没有迁移、降级和故障方案；
承诺了团队无法稳定提供的响应时间、可用性或合规能力；
把关联产品写成独立测评，或把商业关系藏在推荐背后；
用更多提示词掩盖没有真实用户、真实成本和真实验收的问题。

所以，这个项目会坚持几个简单原则：来源可追溯，利益关系明示，结果可复测，风险不美化，未知就标注未知。

十二、我希望留下什么

如果这条路最后没有成为一门足够大的生意，它仍然应该留下三类东西：

一套让我和团队更快、更稳地学习与开发的方法；
一批真实用户可以使用、测试和批评的作品；
一份没有把失败删掉的商业记录，让后来的人知道哪些判断曾经有效，哪些只是当时的愿望。

我仍然想赚钱，因为收入是价值交换能够持续的一种证据；但收入不是唯一的价值，也不是可以提前宣布的结局。眼下更诚实的目标，是把 AI 的能力接到真实的人、真实的组织和真实的责任上，然后看它是否值得继续。

来源与核验说明

个人经历：2022 年软件公司失败、2023 年恢复和 2026 年重新进入 AI 的时间线，见我的故事与创业篇。
项目关联：中国词元云、token.love、ku0.com 与公众号文章见作者项目与现实实践，存在作者关联，不是独立测评。
商业结论：收费方式、成本账本和 12 周路线是待验证方法，不是收入、客户数量、利润或投资回报证明。
官方页面核验：2026-09-01。token.love 与 ku0.com 的首页定位和本章外部文章链接均可访问；具体产品能力、服务范围、地区、政策与合同承诺仍应在实际项目中重新确认。

让方法回到日常

这一章不该把读者留在产品名、架构图和收费接口之间。它真正要留下的，是一种较慢也较诚实的工作姿态：把问题说清，把边界写明，把一次运行、一笔成本和一次失败都放回可被检查的位置。

项目能否继续，最后仍要由用户、团队、合同、时间和责任共同回答。读者可以先去作者项目与现实实践核对关联、状态和证据边界；也可以直接进入第四部：实践与恢复，把这里的判断带回自己的一个小任务、一周节律和一次能够重新开始的行动。

技术把路铺得更快，不代表人已经走到了那里。真正能带过下一段日子的，不是一次漂亮的演示，而是你愿意在现实条件里继续学习、继续交付，也继续修正的那一点能力。