社区到 Agent 的反馈闭环：让网站持续生长

社区只有在改变作品时才真正有价值。如果提问、反对、纠错和案例都留在聊天记录里，社区就只是一个对话层。对一个由网站所有者和 Agent 共建的“活的网站”来说，社区反馈应该变成结构化输入。

目标不是让 Agent 盲目重写网站，而是建立一个闭环：社区信号进入系统，所有者做出判断，Agent 提出修改，所有者决定什么发布、什么标记 featured。

原始反馈的问题

原始反馈是混乱的。

有人在微信群里提问，有人在 Reddit 帖子里反对，有人在 Discord 里分享更好的例子，有人发来私下邮件，有人指出一篇文章太浅，有人问同样的思路是否适用于香港公司、Stripe 或 Telegram 社区。

如果这些信号停留在它们出现的地方，就很难被利用。Agent 无法可靠地读取它们，所有者会忘记上下文，同样的问题以后还会再次出现，文章也得不到改进。

网站需要一层反馈入口。

应该记录什么

每一条有价值的反馈都应该记录：

来源
日期
相关文章或分类
用户的问题或反对意见
上下文
所有者的解读
建议动作
状态
优先级

一条简单的反馈记录可能长这样：

{
  "id": "feedback-2026-07-09-001",
  "source": "reddit",
  "category": "opc-operations",
  "subcategory": "one-person-company-operations",
  "relatedPost": "opc-hk-banking-readiness",
  "signal": "Reader asked how a solo Hong Kong company should explain customer geography to a bank.",
  "ownerInterpretation": "The banking article needs a section on customer geography and transaction narrative.",
  "suggestedAction": "Add examples for consulting, digital products, and community subscriptions.",
  "status": "needs-revision",
  "priority": "high"
}

这不是什么复杂的软件，而是一种记忆格式。

状态设计

反馈需要状态。没有状态，系统就会变成一堆笔记。

一套实用的状态：

captured：信号已记录。

triaged：所有者已阅读并解读。

needs-revision：某篇文章需要修改。

needs-new-article：这个信号值得写一篇新文章。

agent-drafted：Agent 已提出修改。

owner-review：等待人工判断。

accepted：修改已被接受。

rejected：暂时不处理。

featured-candidate：修改后的文章可能值得标记 featured。

这样所有者和 Agent 可以协作，而不用互相猜测。

所有者是编辑

Agent 不应该是最终权威。网站表达什么，由所有者决定。

所有者的工作是解读反馈：

这是真实问题，还是某个人的误解？
它是否暴露了缺失的上下文？
它应该并入现有文章吗？
它值得单独写一篇吗？
它是否符合网站的观点？
它是否应该改变知识地图？

Agent 的工作是把这些判断变成草稿、diff、摘要和一致性检查。

这种分工很重要。如果 Agent 负责解读，网站会变得平庸泛化。如果人负责解读、Agent 负责执行，网站才能保持观点。

featured 应该怎么运作

featured 状态应该意味着：“所有者满意到愿意把这篇当作强入口来展示。”

这意味着它不应该只由浏览器本地状态控制，而应该成为内容或审阅系统的一部分。

一个好的流程：

文章初始为 featured: false。
社区反馈到来。
所有者记录应该改什么。
Agent 修订文章。
所有者审阅。
如果文章成为强入口，所有者设为 featured: true。
热度图和 featured 统计从内容源更新。

关键点是：公开的 featured 状态应该来自仓库数据，而不是临时的 UI 状态。

每篇文章一个审阅文件

一种轻量模型是为每篇文章建一个审阅文件：

{
  "postId": "en/opc-hk-banking-readiness",
  "status": "needs-revision",
  "featuredDecision": false,
  "ownerNotes": [
    {
      "createdAt": "2026-07-09",
      "note": "Add concrete examples for customer geography and expected transaction volume."
    }
  ],
  "communitySignals": [
    {
      "source": "reddit",
      "summary": "Readers are confused about how banks evaluate remote solo founders."
    }
  ],
  "agentTasks": [
    {
      "status": "pending",
      "task": "Revise the banking evidence section with three examples."
    }
  ]
}

这已经足够让 Agent 理解协作的当前状态。

MCP 最终能做什么

MCP 在数据模型建立之后才有用，它不应该是第一步。

当反馈和审阅记录存在于仓库或数据库中之后，MCP 可以暴露这样的工具：

list_feedback
read_article
read_review_state
propose_revision
set_review_status
set_featured
create_article_from_signal

这能让 Agent 直接对接网站的操作系统。

但如果没有持久的反馈记录，MCP 只是在缺失的数据上套了一层工具接口。顺序应该是：先有数据模型，再有 MCP。

社区即产品调研

对一人公司来说，社区反馈就是产品调研。一个反复出现的问题不只是一条评论，它可能是：

一个缺失的文章章节
一份新清单
一个咨询服务
一个模板
一个小工具
一期 newsletter
一场 Discord 活动
一个 Stripe 产品

网站应该能追溯从信号到成品的这条路径。

举个例子：

社区提问：“香港公司没有本地客户能开银行账户吗？”

反馈记录：银行文章缺少客户地域相关的例子。

Agent 任务：新增一节，写三个交易叙事示例。

所有者审阅：修改后接受。

发布变更：文章新增银行叙事章节。

未来产品：可下载的银行开户证据清单。

这就是闭环。

最小可行系统

从简单的开始：

建一个 reviews 或 feedback 目录。

用结构化 JSON 或带 frontmatter 的 Markdown 记录反馈。

加上状态、优先级、相关文章和所有者解读。

让 Agent 在写作前先读这些文件。

让所有者在内容 frontmatter 里决定 featured 状态。

之后再做一个只有所有者可见的仪表盘来展示审阅状态。

这给了网站记忆，也给了 Agent 一个真正可协作的工作面。

原则

社区不应该控制网站，Agent 也不应该控制网站。所有者控制解读。

社区提供信号。

Agent 提供执行杠杆。

网站提供记忆。

所有者提供品味、方向和最终判断。

这就是一个人和 Agent 共建网站的运营模型。