<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[失败复盘]]></title><description><![CDATA[记录失败现象、证据、根因、修复和仍未解决的问题。]]></description><link>https://cohao.cn/category/6</link><generator>RSS for Node</generator><lastBuildDate>Thu, 17 Sep 2026 00:17:38 GMT</lastBuildDate><atom:link href="https://cohao.cn/category/6.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 15 Aug 2026 18:16:19 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[失败模式：用批量 AI 帖子填充冷启动，为什么热闹不等于社区]]></title><description><![CDATA[空社区最让人焦虑，于是很容易想到一个办法：让 AI 一次生成几百篇帖子，再让多个账号互相回复，先把页面填满。
这会同时制造三个假象：好像已经有人使用，好像内容经过讨论，好像社区已经形成共识。新用户一旦发现这些互动不是人发生的，信任损失比看到一个安静的新社区更难修复。
批量内容为什么救不了冷启动

它回答的是编辑部想象的问题，不是成员正在付出成本的问题。
没有人对结果负责，错误和过期内容很快堆积。
回复数量上升，但真实关系、答疑和共同工作没有增加。
数据指标失真，团队无法判断哪些内容真的有价值。

COHAO 采用的替代方案

编辑部只发布数量有限、来源透明的种子内容。
所有种子帖标记 AI 协助与人工复核，不伪装普通成员。
留出明确问题和公开任务，让真实参与从纠错、复现和补充开始。
统计真实用户、有效回复、被解决的问题和持续维护，不把编辑部批量输出算作社区活跃。

社区可以从内容开始，但内容必须给真人留下位置，而不是提前替真人把所有话都说完。

编辑说明：2026-08-15，本文说明 COHAO 的冷启动选择，不声称存在已经发生的批量造假事件。AI 协助起草，项目负责人复核。
]]></description><link>https://cohao.cn/topic/14/失败模式-用批量-ai-帖子填充冷启动-为什么热闹不等于社区</link><guid isPermaLink="true">https://cohao.cn/topic/14/失败模式-用批量-ai-帖子填充冷启动-为什么热闹不等于社区</guid><dc:creator><![CDATA[COHAO编辑部]]></dc:creator><pubDate>Sat, 15 Aug 2026 18:16:19 GMT</pubDate></item><item><title><![CDATA[失败模式：把密钥写进日志和对话，后续删除为什么不够]]></title><description><![CDATA[密钥一旦进入对话、终端回显、日志、截图或错误上报，之后把那一行删除并不等于风险消失。它可能已经被同步到备份、日志平台、浏览器历史、剪贴板、会话记录或第三方监控。
常见入口

在命令行参数里直接传密码，随后被进程列表或 shell 历史记录。
为了排查问题打印完整环境变量或请求头。
把真实配置文件贴给 Agent，让模型“帮忙看看”。
错误处理把 Cookie、Authorization 或数据库 URL 一并记录。
截图里出现二维码、Token、邮箱验证码或管理地址。

发现后应该做什么

立即撤销或轮换密钥，不把“已经删除”当作补救完成。
查清它出现在哪些系统、备份和人员可见范围内。
检查密钥使用日志与异常访问。
修复产生泄露的日志、调试和工具接口。
记录事件时间线，但在事件记录中也不要再次复制秘密。

预防比清理便宜
使用受限环境文件、密钥管理服务、标准输入或短期凭据；日志默认脱敏；Agent 工具只接收业务参数，不接收原始密钥。生产凭据不进入仓库、文档和聊天。

编辑说明：2026-08-15，COHAO 编辑部根据生产运维通用原则整理；AI 协助起草，项目负责人复核。
]]></description><link>https://cohao.cn/topic/13/失败模式-把密钥写进日志和对话-后续删除为什么不够</link><guid isPermaLink="true">https://cohao.cn/topic/13/失败模式-把密钥写进日志和对话-后续删除为什么不够</guid><dc:creator><![CDATA[COHAO编辑部]]></dc:creator><pubDate>Sat, 15 Aug 2026 18:16:19 GMT</pubDate></item><item><title><![CDATA[失败模式：把管理员能力交给 Agent，出问题时谁也说不清]]></title><description><![CDATA[把后台管理员账号直接交给 Agent，看起来可以少写很多工具接口：模型想查什么就查，想改什么就改。但一旦出现误删、越权或提示注入，系统很难回答三个基本问题：谁授权的、允许到哪里、怎样撤销。
这种设计会失去什么

对象边界：管理员通常能看到所有租户和用户，模型只靠提示词区分不了所有权。
动作边界：查看、编辑、封禁、退款和改权限被压缩成同一个高权限会话。
责任边界：日志只显示管理员账号，无法区分用户意图、模型决策和工具执行。
故障边界：凭据泄露或插件被污染时，影响范围是整个系统。

更窄的替代方案
为每类允许动作建立专门工具，例如“读取本人订单状态”“为本人草稿生成摘要”“提交待审核的退款申请”。后端从认证会话派生用户与站点，检查对象所有权，限制字段，记录确认和幂等键。
模型不应该拥有数据库、管理员面板、角色修改、钱包或密钥管理入口。即使未来 Agent 更聪明，这些边界也不会过时，因为它们解决的是责任与权限问题，不是语言理解问题。

编辑说明：2026-08-15，本文是上线前威胁建模，不声称 COHAO 已发生该事故。AI 协助起草，项目负责人复核。
]]></description><link>https://cohao.cn/topic/12/失败模式-把管理员能力交给-agent-出问题时谁也说不清</link><guid isPermaLink="true">https://cohao.cn/topic/12/失败模式-把管理员能力交给-agent-出问题时谁也说不清</guid><dc:creator><![CDATA[COHAO编辑部]]></dc:creator><pubDate>Sat, 15 Aug 2026 18:16:19 GMT</pubDate></item><item><title><![CDATA[失败模式：工具超时后盲目重试，为什么可能把一次操作执行两遍]]></title><description><![CDATA[下面不是虚构事故，而是一种需要在上线前主动防住的常见失败模式。
假设 Agent 调用“发布文章”工具，外部服务已经收到请求并成功创建文章，但响应在返回途中超时。Agent 只看到超时，于是再次调用，最终产生两篇完全相同的文章。
为什么普通重试策略失效

超时表达的是结果未知，不是执行失败。
创建、付款、发送、删除等写操作通常不是天然幂等。
模型可能把“再试一次”理解为最合理的恢复动作。
如果日志只记录返回结果，没有记录提交前状态，就很难判断第一次是否发生。

应该怎么设计

每次业务动作由后端生成稳定幂等键。
工具先写入 pending 状态，再发送外部请求。
超时进入 unknown，随后用查询接口或外部请求标识核验。
只有后端确认第一次未发生，才允许重新执行。
如果无法查询，就转人工，不让 Agent无限重试。

验收测试
测试时故意在“外部已成功、响应未返回”的位置断网，验证系统只产生一个对象，并且最终能从 unknown 收敛到 succeeded 或人工处理。

编辑说明：2026-08-15，COHAO 编辑部将通用分布式系统风险转化为 Agent 工具调用检查项；AI 协助起草，项目负责人复核。
]]></description><link>https://cohao.cn/topic/11/失败模式-工具超时后盲目重试-为什么可能把一次操作执行两遍</link><guid isPermaLink="true">https://cohao.cn/topic/11/失败模式-工具超时后盲目重试-为什么可能把一次操作执行两遍</guid><dc:creator><![CDATA[COHAO编辑部]]></dc:creator><pubDate>Sat, 15 Aug 2026 18:16:19 GMT</pubDate></item><item><title><![CDATA[复盘：只看搜索摘要，为什么会把论文和结论引用错]]></title><description><![CDATA[这是一条真实的项目复盘。我们在为 COHAO 创世方案补研究依据时，曾经根据搜索结果摘要组装论文引用。摘要看起来支持结论，但进一步核对后发现，部分论文编号、标题和主张范围并不对应。
失败是怎么发生的

搜索摘要截断了原文，只保留最像答案的一段。
相近主题的论文被混在一起，标题、作者、编号和结论发生错配。
二手页面把相关性写成因果性，计划稿又把它当成原论文主张。
引用格式正确，让错误显得比普通文字更可信。

修复流程

通过论文主页、DOI、Crossref 或 arXiv API核对标题、作者、日期和标识符。
阅读摘要和与主张直接相关的段落，不根据搜索摘要扩张结论。
把“论文发现”“作者讨论”“我们的推断”分开写。
对每个引用保留主张到来源的映射，自动检查正文引用与参考文献是否一一对应。

后续规则
搜索结果只能用来发现候选来源，不能单独作为研究结论的证据。一个引用如果无法回答“原文到底说了什么、适用于什么范围”，宁可暂时不写。
这次修正后的研究稿重新核验了论文标题、作者、摘要与主张范围，也让我们把“来源核验”列为编辑部 Agent 可以协助、但必须由人负责的流程。

编辑说明：复盘事件发生于 COHAO 方案研究阶段，本文于 2026-08-15 整理。AI 协助结构化，项目负责人核对事实。
]]></description><link>https://cohao.cn/topic/10/复盘-只看搜索摘要-为什么会把论文和结论引用错</link><guid isPermaLink="true">https://cohao.cn/topic/10/复盘-只看搜索摘要-为什么会把论文和结论引用错</guid><dc:creator><![CDATA[COHAO编辑部]]></dc:creator><pubDate>Sat, 15 Aug 2026 18:16:18 GMT</pubDate></item></channel></rss>