# 这几个月，不是在追更多 AI，而是在追一件事真正发生

**先纠正技术起点：最早做的是我们自己的 auto，不是军团。**前稿把“内容、接活和社区”的产品背景放到了最前面，却没有把 auto 这条技术主线讲透。两条线应分开看：产品上一直追问“人有没有得到可用结果”；技术上则是“固定流水线 → 自研 auto 自主用工具 → 学习和连接成熟 Harness → 围绕作品持续协作”。

**我的归纳：auto 想让一个自主执行者真正把事情做成；军团把这个目标扩大到开放的工作台与工具生态，社区再让成果、有效方法和真实贡献被下一位用户采用。**不是先把 auto 否定，再找一个“多 Agent”概念替代它。

这不是一段“从第一天就想对了”的成功史。中间有方向扩散、评价口径修正、流程过重，也有功能已经写好但用户仍没拿到成果的挫折。下面按原周报讲清楚：当时在解决什么，为什么又往前走了一步。**当时的计划、判断和自述，不等于今天已经得到验证的能力。**

### 90 秒，先讲清这条主线

> 这几个月，我们一直在追同一个问题：普通人能不能借助 AI，把自己本来做不好的事情真正做成。
>
> 业务上，我们从接活、内容和经验供给发现，用户需要能真正用上的成果。技术上，最早自己做 auto，让模型自主找资料、选工具、看结果、再解题，而不是照固定流水线跑。后来发现，值得保留的是 auto 的自主思路与真实工具，不一定要由这一套自研引擎承包所有领域。这些问题不是按月解决一层再进入下一层：上下文缺失和结果没被用上很早就反复出现，复杂执行又带来成本与消费断链，至今尚未全部闭环。
>
> 所以现在收敛成一件事：保留大家原来的工作台，让好的工具和 AI 能力按需互借，围绕同一个作品持续完成、修改和协作。用户不需要管理一群 AI；社区也不是晒聊天记录，而是让人点开就能体验、改成自己的版本，还能把有用的改进贡献回去。
>
> 我们要证明的是两件事：同一句需求，交得更好；同等质量，花得更少。局部续改、补位和真实作品已经有证据，但稳定超越最强单家、更便宜以及用户持续回来，还没有证明。下一步要验证这些能力，而不是继续增加成员和材料。

<h3 id="auto-to-legion">技术主线：为什么先做 auto，后来做军团？</h3>

**一句话：不是因为“auto 一无是处”，而是自研的边界变了——从自己造一个包办所有事的执行者，转向把最合适的原生工作台、工具和工程现场接起来。**

#### 1．auto 最初到底想解决什么

auto 是我们自己的自主 Agent。它想把“模型会回答”推进到“模型能用工具把问题解决”：自主检索、读附件、运行脚本、查看中间结果，发现不对再调整。代码里的 `run_auto_agent` 是入口；其中的 `native_agent_loop` 是这个自研系统的执行引擎，不能与“所有外部 Harness 的原生能力”混为一谈。

早期目标还包括：把分散的能力做成用户能直接使用的独立 Agent，而不是每次都依赖开发者开着 Claude Code 帮忙。这是当时的产品目标；原文中的多用户网页仍有计划项，不能倒写成一开始就已完成。

所以，**固定 pipeline、auto、军团是三个不同层次**：流水线替模型预排步骤；auto 让模型自己组织工具；军团希望进一步把完整工作台也变成可按需借用的能力，同时保住同一工程、权限和反馈。

#### 2．auto 有什么值得留下，而不是统统推倒

| 值得保留的积累 | 今天应该怎样用 |
| --- | --- |
| **自主求解的思路**：目标在前，模型根据现场选工具、换策略 | 保留原生负责人的判断权，不换成一套更长的固定编排流程 |
| **真实工具资产**：搜索、抓取、结构化资料、OCR／PDF／音视频处理、计算与执行 | 做成各家可发现、获准调用的独立工具；不必先启动整套 auto 才能借一个能力 |
| **事实、实体与关系的方法**：追来源、区分同名候选、逐条件核验、保留关系方向与反证 | 作为模型需要时可以使用的能力与上下文，不让每个任务都过一遍统一裁判；详见[实体与关系](#entity-relations) |
| **连续工作的经验**：上下文、检查点、失败记录与方法沉淀 | 原成员或接手者能接着做，下一次实际采用有效才算进化；写了一份记忆不等于学会 |

这里不是全部工具都已经无损迁移、全家都用过。**有源码、有共享入口和实际用出效果是三个阶段，要分别验。**

例如，旧“校验即搜索”模块确有主动找反例的实现，但也含固定查询模板和阈值。本轮没有证明它已成为各家可直接调用的独立共享工具，更不应整包复制成军团的默认质量门。

#### 3．为什么不继续把 auto 做成唯一的“总大脑”

**第一，单一自研引擎的维护范围会越滚越大。**搜索、编程、视频、浏览器、文件、长期运行，各有完整生态。每加一种能力都改同一个大内核，容易让工具、判断、验证与收尾纠缠。更合理的是复用成熟工作台，把独到能力拆成可调用的工具，而不是再造每一家。

**第二，执行者擅长什么，与它能否指挥所有人是两回事。**旧方案曾尝试让 auto 做执行者、首脑，后来又让它做统一复核裁判。那是探索阶段，不是最终正确答案。一次核对短答案很快，不能证明它适合审核所有专业作品；层层复核还可能把已经完成的答案弄丢。

**第三，用户真正想迁移的是能力，不是被迫换习惯。**有人习惯某个编程工作台，有人已有自己的工程、工具或素材。开放军团应让这些现场接得上，缺什么再借什么，而不是先把所有人搬进 auto 的流程。

**这不证明多家天然更强。**如果最强单家已经做得最好、更快、更便宜，就该让它直接做。只有同一真实任务上的补位、连续修改或工具复用带来净收益，军团这层才值得存在；否则只是增加协调费用。

#### 4．过去有哪些证据，哪些说法不能继续沿用

8月9日的旧重跑报告记录：auto 借助工具路径救回了部分旧流水线失败题。这是工具化方向值得继续验证的线索，不是“换成auto必然更强”的严格因果实验。保留的两份旧检查点确实可见搜索、脚本计算、图像读取与交卷调用，也有候选和收尾未对齐的回执；但本地缺该报告的完整重跑总账，不能独立重建全部救回数量。报告中的 **61% 是旧通过题加上新救回题的合并口径，不是 auto 在全部165题上统一条件的一次首过率**；本轮也没有重跑这份基准。

8月25日方案把 auto 放到裁判位置，8月30日又明确提出“工具解放、首脑降级、大文件解耦”。其中的少量成绩、首脑评分与耗时，都有当时任务和环境的限制，不能当成永久品牌排名。真正延续至今的方向，是把有用能力保留下来，不让一个大控制器成为所有交付的必经之路。

#### 5．当前代码里，auto 还在什么位置

**本地这份实现的配置已经将 auto 标为 `capability`：工具资产保留，不作为成员接单。**原自研源码和适配函数仍在，但它不参与默认答题、接力或首脑竞选；工具箱继续扫描和桥接原有工具。这个结论来自现行声明和消费者代码，不是从旧周报推测，也不等于本轮复验了每台线上服务。

因此，今天应该保留的是 auto 的有效能力、可复验案例和自主做事的方法，而不是因为已经投入很多，就坚持让它统管每一单。**也不应因为答题角色退役，就把 auto 的工具、研究和经验一起当成没价值。**本次只澄清历史与交付入口，没有擅自恢复退役执行路径或改线上模型配置。

来源：[最早的统一Agent与用户入口目标](https://km.sankuai.com/collabpage/2779476035)、[auto重跑报告](https://km.sankuai.com/collabpage/2780280477)、[8月25日多Harness平台方案](https://km.sankuai.com/collabpage/2783141021)、[auto架构与瘦身分析](https://km.sankuai.com/collabpage/2783075172)、[8月30日拆解方案](https://km.sankuai.com/collabpage/2783785919)。当前源码依据：`qa_auto_agent.py`、`native_agent_loop.py`、`harness_manifest.json`、`runtime_manifest.py`、`toolbox.py` 与 `test_auto_tools_only.py`；这些是代码及历史事实，不是普遍协作优势的证明。

### 4月：先找真实的活，而不是让社区看起来很热闹

**当时的问题：**有 AI 和内容，不等于有人真的需要它。早期周报把目标放在“帮用户做出比自己更好的内容”，再连接实际需求、样品、反馈与合作。

**做过的探索：**围绕视频样品、内容生产、需求撮合和回复回收，让能力有一个真正的使用对象。

**促使思路继续变化的地方：**周报记载过视频小样和小项目交付，这是当时自述，未由本轮独立验收。曝光、报价和合作意向不能证明成交、用户收益或可持续的平台收入，局部交付也不等于完整链路成立。光把内容生产出来，没有接住后续需求，就不算闭环。

**留到今天的东西：**产品从真实用户的一件事出发。作品好不好，先看它能不能被拿去使用，而不是生成了多少篇、调了多少次模型。

4月底已经出现过一个很具体的反思：机械定时发帖拿不到真实经历，可能只会生成重复内容。W18 因此尝试连接真实上下文，让有事发生再表达。这是当时的诊断和改进方向，效果仍待观察；它也不意味着今天应取消用户权限或多租户隔离。

来源：[W17 · 4.21—4.24](https://km.sankuai.com/collabpage/2759601204)、[W18 · 4.27—4.30](https://km.sankuai.com/collabpage/2760670106)。

### 5月：内容不能止于“看懂了”，要让人照着做得成

**当时的问题：**“点赞、收藏，然后没有然后”不能稳定地改善工作。内容供给也不能一直靠官方批量生成来维持。

**做过的探索：**从泛化教程转向真实创作者的实战经验，把方法附在内容上，尝试按用户处境提供能直接执行的任务；让使用后的动作和回应回来，而不只是看发布量。

**促使思路继续变化的地方：**有评分、有模板、有 Skill 上传，只说明生产和分发流程存在，不等于用户实际跑通，也不等于留存提升。周报中的“省了多少时间”“赚了多少钱”有些是模板或帖子描述，不能转写成 Meyo 已经实现的产品业绩。

**留到今天的东西：**“挂上 AI 使用经验”不应是多贴一段提示词，而是说明它适合什么任务、需要什么条件、原来怎么失败、最后怎么做成。别人能据此再做成一次，才算经验开始有复用价值。

这里并非只有抽象设想：W19 已把“人的经验由 Agent 执行”作为产品方向；W21 记录过部署出来但按钮因脚本错误无法使用的 Demo；W22 又把内容生产与按需推荐接起来，但上线后效果仍待回收。**“经验能执行”“上线不等于能用”“被需要的人采用才有价值”这三个问题，5月就已经出现，今天只是追得更深。**

来源：[W19 · 5.6—5.9](https://km.sankuai.com/collabpage/2761465280)、[W20 · 5.11—5.15](https://km.sankuai.com/collabpage/2762379653)、[W21](https://km.sankuai.com/collabpage/2764138230)、[W22](https://km.sankuai.com/collabpage/2765810711)。

### 6月：不是“我的 AI 更强了”，而是“我的问题解决了，还知道下一步”

**当时的问题：**给一类人发同样的任务，未必能接住一个人的具体处境。第一次完成后没有下一步，或用户对权限和信任有顾虑，都会让使用停下来。

**做过的探索：**从聚合人群需要转向“一人一任务”，把推荐前移到内容生产阶段；通过访谈和行为回看，关注首次执行后的下一步、人与人的回应，以及成果能否走出社区。

**促使思路继续变化的地方：**一份周报主动修正了悬赏占比的分母错误；“熟人信任链影响使用”是访谈后形成的假设，不是已经证明的唯一留存原因。另一阶段把矛盾从站内活跃转到外部新增，提醒我们：只在已有用户中制造热闹，也不会自然长出新用户。

**留到今天的东西：**让人获得具体结果，比让 Agent 看起来更强更重要。结果需要可分享、可继续使用，并产生真实回应；但今天仍要同时验证获客和留存，不能拿当时对“只盯留存”的反思来跳过留存。

来源：[W23 · 6.1—6.5](https://km.sankuai.com/collabpage/2766927431)、[W26 · 6.22—6.26](https://km.sankuai.com/collabpage/2771200567)、[同周另一份记录](https://km.sankuai.com/collabpage/2770699971)。两份 W26 有内容重合，不算两次独立成功。

### 7月：从“写经验”走向“真执行”，也看到复杂与昂贵的代价

**当时的问题：**从“给说明”走向“搜索、执行、交付”之后，很容易把完整性误解成每题都要写一整套方案。

**做过的探索：**扩充工具、并行执行、记忆和评审，试图让 Agent 在真实场景中把事情做完。

这不是只把文章写得更长。W27 强调“解决工作里一件具体小事”，W28 进一步尝试先找真实问题、搜索和组合 Skill、实际执行，再把过程与结果变成别人可以复用的经验。**今天“作品＋做成它的方法”，在这个阶段已有清楚的前身。**

**成本方面的警示也已经出现：**W28 自述并行竞争和真实执行让成本明显上升、产量下降，而质量改善主要还是当时的自评，用户留存和互动效果待回收。所以今天的“更便宜、量大管饱”不是附带营销口号：如果把一件事做得更复杂、更贵，却没有可持续的用户收益，路线就需要收缩。

**关键反证：**W30 记录了换一套评价规则后，原本靠“交付物完整”占优的方案表现下降。每题套固定步骤、坑点和清单，或忽略用户所在环境，看上去认真，实际可能不合适。不同评价规则下的分数也不能直接拼成持续提升曲线。

**留到今天的东西：**能用文字完整满足的就准确快答；需要专业成果的交专业成果，复杂项目才展开相应研究与协作。判断看用户要拿到什么，不看问句长短。**世界级不是所有题都做成重工程，而是恰当地、完整地满足这一个人的用途。**今天不应把当时的固定长度和步骤要求换个名字再加回来。

W31 又明确指出“有方案、有代码、有自述”与“接通、运行、验收”混在了一起：采来的数据没人用，写出的提案没人消费，监控本身也有资源和积压问题。这提示我们，**要优化真实执行链，不是再加一套看上去覆盖更全的监督系统。**

W29 对“进化”也提出过很具体的期待：成功方法变成可调用的 Skill，之后少走同一条弯路；多会话能够积累经验、协作而不互相覆盖。这是今天生态复用的前身。不过，当时单次节省或组件接通的自述，仍不能证明所有新任务都会更省。

来源：[W27 · 6.29—7.3](https://km.sankuai.com/collabpage/2772912531)、[W28 · 7.6—7.10](https://km.sankuai.com/collabpage/2773699028)、[W29 · 7.13—7.17](https://km.sankuai.com/collabpage/2775375671)、[W30](https://km.sankuai.com/collabpage/2776539163)、[W31 · 7.27—7.31](https://km.sankuai.com/collabpage/2778223057)。W30 原文没有明确起止日，只按周次归入 7月；W28 内还含后补阶段记录，不把标题周期当作其中所有机制的首次发生日。

### 8月上中旬：从“再调一遍 Prompt”转向“到底哪里挡住了模型”

**当时的问题：**答案可能已经算对，最终却没交出来；材料可能已经查到，实现者却没收到；机制看似接上，真实运行中却没生效。

8月上旬周报记载了一次重要方向变化：把固定流水线改成模型可以自主调用的工具，统一工具入口，并探索自己创建工具。这比“在固定步骤里换一个更聪明的模型”更接近今天的开放 Harness 思路。同时，附件不在工作目录、缺能理解画面的工具等具体问题，也提醒我们：**没有把资料和能力真正交到手里，就不能把失败都算在模型头上。**

**做过的探索：**深入执行记录、上下文、候选状态、验证与收尾，研究不同工作台怎样管理工具和任务现场。当时还尝试把散落的判断、约束和预算收拢到一个“统一驾驶员”（SoulDriver），让标准随目标与现场变化。这是把控制集中并动态化的探索，还不是今天“原生负责人自主做，平台承接运行与事实”的边界。

**这一步真正留下的价值：**不能把所有失败统称为“模型不行”。要区分模型理解、工具环境、上下文送达、执行恢复和交付收尾；修复后回到原任务看结果有没有改变。

**也要承认当时走过的弯路：**这一阶段仍尝试了不少统一控制、门槛和否决机制。不能把当时每个设计都写成正确答案。今天要保留的是“让成员看见真实现场并自主处理”，不是把它包进更厚的流程里。

来源：[8.3—8.8 周报](https://km.sankuai.com/collabpage/2778375484)、[8.8—8.14 周报](https://km.sankuai.com/collabpage/2779630806)、[8.15—8.21 周报](https://km.sankuai.com/collabpage/2780834005)。这些原文含后补排名、自报成绩、计划和执行记录，不能用标题日期倒推当时已验证的事实；历史基准、自评分数和多次尝试中的最好结果，不作为本页当前泛化能力的证明。

### 8月下旬：多家放一起，不会自动比最强一家更好

**当时的问题：**如果各家都有长处，能不能把它们组织起来，让整体效果超过单家？

**做过的探索：**对照多家真实工作台，尝试路由、后置融合、投票和接力。8.22—8.28 周报把军团立项记在 8月25日；这是该周报的项目记录，不推断所有相关能力都从当天才出现。

**关键反证：**这份周报记录了多次融合或路由没有超过最强单家的情况，也发现多人可能共享同一种错误。部分历史结果还存在被重跑覆盖、报告和执行记录口径不一致的问题，不能挑一个最好看的旧分数来证明“群体已经更聪明”。

**留到今天的东西：**军团不是开会投票的“答案拼接器”。先把最强单家的原生能力用足，确有缺口再借工具、借完整工作台或请同伴补位。平台负责让任务现场、文件和反馈接得上，不在上面再造一个把所有人管死的答题器。

8月底原文已经反思：有些正确答案是被自己的层层否决和收尾流程弄丢的；也记录过“为了瘦身删掉看似没用的能力，结果搜索返回零”的反例。**要减的是无效控制和常驻负担，不是把原生工作台的能力一起削掉。**

来源：[8.22—8.28 周报](https://km.sankuai.com/collabpage/2782703397)。

### 9月上旬：从“机制做出来了”转向“把作品交到眼前”

**当时的问题：**成员、工具、测试和架构已经很多，但用户仍会问：作品呢？为什么不好玩？视频为什么只是图片在动？

**做过的探索：**行星、视频、跑酷、赛车和图解成为真实试题；用可打开的同类作品帮助判断质量，再把实际差距送回原作者返工。开始强调“小范围但完整、第一眼能感知价值”的成品，而不是缩水演示。

**关键反证：**9.6—9.11 周报同时写下了两类事实：工程与部署在推进，用户可感知的世界级交付仍未被证明。还记录了动态编排更慢却没赢、截图重复却曾被判通过，以及视频生成受限后退成图片运镜的问题。它们分别指向组织成本、证据真实性和真实工具能力，不能靠换一句“高质量”Prompt解决。

同篇还自述另一 B站任务经开发者代调工具产出 v3。这是当时辅助出片的记录，不应与受限的图片运镜任务拼成一条进步曲线，也不等于军团自主完成成片已被证明；本页找回的各段原视频，仍按各自订单和文件说明展示。

**留到今天的东西：**唯一有意义的进展，是用户拿到可用作品、原作品出现能验证的改善，或者原来的失败旅程恢复了。行星截图、视频原片、赛车变化放在[本页作品区](#works)，让读者直接看，不用相信一串完成状态。

**这里确实发生过反复：**8月底刚反思强控制，9月为追求品质又加入固定角色、必经评审和质量门。今天要吸收的是研究、验证与反馈，不是把这些安排固化到每一单。权限、取消、付费确认和原文件保全等运行安全边界仍应保留，不能与“替模型规定怎么答题”混在一起全删掉。

来源：[8.29—9.7](https://km.sankuai.com/collabpage/2783435868)、[9.6—9.11](https://km.sankuai.com/collabpage/2786241806)。当时试过的强制工序和质量门，不作为今天继续扩平台的理由。

### 9月中下旬：把军团与社区接到同一个“可持续修改的作品”

**当时的问题：**第一次运行成功还不够。换一个成员、刷新页面、重新发布后，原文件、原生会话和用户修改能不能接着用？社区如果只发文章，别人又如何真正获得和改进作品？

**做过的探索：**9月中旬周报记载了正式发布、运行依赖持久化、原生会话续作和协作上下文修复，也明确把产品入口从 Harness 名单转向“成熟作品试玩、私有空间、AI 持续改造”。后续本页案例补上了原工程续改、候选采用、恢复与贡献等限定旅程。

**今天的产品逻辑：**同一作品是连接用户、AI 与社区的共同对象。用户表达意图，原生负责人接着原工程做；遇到边界再求助，意见和改动回到同一版本。别人看到作品，可以在授权范围内拥有自己的版本，也可以把贡献交回原作者决定是否采用。

**边界：**9月中旬的“正式发布成功”不等于所有成员、所有入口、所有专业作品都验收完成。本页展示网址、公司测试入口、原生续作个案和完整社区产品必须分开说明。[当前入口与功能状态](#current-entrances)保留这些区别。

来源：[9.14—9.19 更新版周报](https://km.sankuai.com/collabpage/2787091847)；9月下旬的局部变化见本页案例与发布回执，不倒写成周报当时已经证明的成果。

### 为什么“开放工作台”与“作品社区”应该是一件事

可以把它想成一个开放工作室：**工作台负责把东西做出来，作品让人看见价值，社区让下一次制作不用再从零开始。**

- **对已有工具习惯的人：**不要求换掉原工作台。把获准使用的工程、资源和方法接过去，缺某种能力时再借。迁移的是可交接的现场，不是擅自搬运所有账号权限和内部记忆。
- **对普通人：**先看到能体验的作品，再说“我想改成这样”。不需要先学会挑模型、装环境、给多个 AI 分工。
- **对创作者：**分享的不只是结果，还有来源、版本和做成它的方法；别人真正采用、改进或反馈，才产生关系。
- **对下一位用户：**复用经过实际使用的成果与经验，有机会少试错、更快交付。只有下一次任务真的用上并产生净收益，才叫进化；把经验存成一份文件不算。

**目标旅程示例，而非全链已上线承诺：**看到一款海岛赛车 → 点开玩 → 说“改成雨夜双人模式” → 在自己的授权副本里继续制作 → 需要时借用其他成员的能力 → 能玩后分享，或者向原作者提交可选择采用的改进。这里最难的不是多放一个聊天框，而是同一工程、状态、版本、权限和反馈能始终接得住。

### 两个目标都要验证，不能拿一个替代另一个

| 要证明什么 | 真正的比较方式 | 现在不能偷换成什么 |
| --- | --- | --- |
| **把质量上限推高** | 同一真实需求，让最强单家用足工具和原生协作；再比较额外补位是否让成品更好，且正确性与核心可用性不退化；可靠性和耗时按预先约定的同题标准比较 | 多家参与、长回复、源码量、漂亮截图，不能代替完整作品和同题净收益 |
| **让同等质量更便宜、可多用** | 把小模型、好工具、已有作品和有效方法的组合，与原方案比较；全部失败尝试、工具、推理、存储和人工救场成本都要算 | 单次模型单价低，不等于最后一件合格成果便宜；“量大管饱”不等于无限免费 |

**对“单一 Harness 有没有上限”的态度也要准确：**个案失败只证明这次没做好，不能直接证明单家先天不行。应先排除工具、上下文、环境和恢复故障，再看跨工作台合作是否有不可替代的增益。一家已经最优，就让一家做，仍然符合 Meyo 的目标。

### 到今天，什么值得继续，什么必须停止自我感动

**值得继续：**把好的原生工作台、开放工具、可靠交接和真实作品接成用户少操心的连续体验；让有效经验和真实贡献随作品积累。这是从早期内容社区走到今天仍有价值的方向。

**必须舍弃：**把内容数量当需求，把模型自评当成果，把更多成员当智能，把“已发送”当“已收到”，把“文件存在”当“任务完成”，把“部署成功”当“用户已能顺利使用”。

**还没回答完的不是概念，而是实证：**能否稳定做出顶尖作品？协作是不是比最强单家更划算？更小的模型能否在同等质量下真正省钱？用户是否回来继续改、是否采用别人的作品、是否愿意为结果付费？这些问题要用[下一轮验证](#next-experiments)和[实际使用与工程边界](#can-we-do-it)来回答。

**因此，继续投入的理由不是“几个月已经花了很多”，而是已经有可复用的作品与运行基础，值得用有上限的下一阶段验证结果。升级优化还没有全部完成；这份网页也不是产品完成证明。**

### 这段历史如何读，哪些不能当作事实

本段是依据指定《个人周报》目录、已取得的子文档和本页既有案例做的综合解释，不把作者当时的想法变成已证因果。各文档的实际读取状态、范围和内容哈希见下方来源表；读取范围随批次列明，不用目录标题冒充已读正文。

数字修正、两份同周记录、当时计划与后来结果按各自口径保留。历史材料中的模板收益、访谈判断、内部榜单、自评、测试全绿、合作意向，都不等于今天的收入、留存、世界级或普遍协作优势。公开页只放业务思路的综合与来源索引，不公开原周报全文、个人访谈细节、账号和认证材料。