从 GitHub 外推脚本到平台无关的信号贡献引擎

很多面向开发者的自动化项目都有着相同的开场。

你找到包含特定关键词的 GitHub Issue。 你生成一条回复。 也许你提到了自己的项目。 也许有人点击访问了。

效果还算不错，以至于的下一步看起来显而易见：

加入更多 GitHub 搜索。

这可能是一个错误的抽象。

真正可复用的系统不是 GitHub 外展管道。 而是一个平台无关的 Signal → Contribution Engine。

GitHub 只是一个适配器。 同样的推理过程应该能跨平台工作：

• GitHub Issue 和 Discussion
• Slack 和 Discord 对话
• Linear 或 Jira Issue
• 内部客户工单
• 任何出现具体技术问题的数据源

平台会变。 智能内核不应变。

The invariant pipeline

核心工作流如下：

TARGET
  ↓
INGEST
  ↓
NORMALIZE
  ↓
THREAD / ARTIFACT UNDERSTANDING
  ↓
SIGNAL EXTRACTION
  ↓
FIT SCORING
  ↓
CONTRIBUTION GAP
  ↓
REPO / PRODUCT MATCH
  ↓
DRAFT
  ↓
HUMAN GATE
  ↓
PUBLISH
  ↓
OBSERVE RESPONSE
  ↓
UPDATE TARGETING POLICY

重要的一点是，这个管道几乎不需要知道什么是 GitHub Issue。 只有 ingestion 和 publishing 需要平台特定的行为。 它们之间的所有环节都应该在一种通用表示上运作。

Configuration, not hardcoded targeting

平台、目标、制品和目标都应该作为输入。例如：

platform:
  type: github
  target: "run-llama/llama_index"

objective:
  primary: qualified_repo_inspection
  secondary:
    - substantive_reply
    - maintainer_engagement
    - star
    - issue
    - pr

artifact:
  repo: leadingproblemsolver/living-context-engine
  claims_file: artifact_capabilities.yaml

target_policy:
  prefer:
    - active
    - low_comment_count
    - unresolved
    - technically_specific
    - buyer_or_maintainer_present
  reject:
    - solved
    - saturated
    - duplicate
    - promotional_thread
    - artifact_fit_is_incidental

publishing:
  auto_publish: false
  require_human_review: true

引擎不应该包含这类硬编码假设：

if repo == "some-project":
    ...

if "memory" in issue.title:
    ...

而应该基于以下维度运作：

Platform × Target × Artifact × Objective

这样同一套引擎可以用于完全不同的任务。

GitHub × agno-agi/agno × living-context-engine × repo_inspection

Reddit × r/devops × constraint-intelligence-engine × pain_validation

Hacker News × newest × operational-automation-service × buyer_discovery

无需重写核心代码。

Normalization is the real abstraction

这是最关键的架构层。 每个平台对象都应该被转换为一种规范化的 signal schema。

一个 GitHub Issue 可能变成：

signal:
  platform: github
  container: run-llama/llama_index
  object_type: issue
  object_id: 22248

  title: ...
  body: ...
  replies: [...]
  participants: [...]
  timestamps: [...]
  labels: [...]

  state:
    open: true
    solved: false
    existing_fix: false
    saturation: low

  problem:
    symptom: "derived prompt is stale"
    authoritative_state: "ctx.store['state']"
    derived_projection: "LLM-facing state prompt"
    failure_mode: "projection not invalidated after state mutation"

  opportunity:
    missing_primitive: "revision-bound projection invalidation"
    confidence: 0.94

一旦这个结构存在，推理引擎就不再关心原始对象是：

• Stack Overflow 问题
• Hacker News 帖子
• Slack 讨论

它看到的是一个具有状态、证据、参与者、问题模型和未解差距的技术信号。 这是一个比给每个平台单独构建推理逻辑强得多的边界。

Platform adapters should be boring

平台接口可以保持刻意的小巧：

class PlatformAdapter:
    def discover(self, target, queries) -> list[RawObject]:
        ...

    def fetch(self, object_id) -> RawObject:
        ...

    def fetch_replies(self, object_id) -> list[RawReply]:
        ...

    def normalize(self, raw) -> SignalObject:
        ...

    def publish(self, object_id, text) -> PublishResult:
        ...

    def observe(self, object_id) -> EngagementState:
        ...

然后实现可以是：

GitHubAdapter
RedditAdapter
HNAdapter
DiscourseAdapter
SlackAdapter
DiscordAdapter
CustomRESTAdapter

适配器应该回答的问题：

• 如何获取这个对话？
• 如何在这里发布内容？

不应该回答的问题：

• 这个问题有趣吗？
• 存在有用的贡献差距吗？
• 我们的制品真的能解决其中一部分吗？

这些属于核心引擎的职责。

The artifact needs a machine-readable truth boundary

贡献自动化还有另一个问题。 一旦系统了解你的项目，它很容易开始夸大项目的实际功能。 某个帖子提到了"memory"。 你的项目有某种模糊相关的持久化功能。 生成的回复突然听起来像你的项目是一个自主记忆系统。

这就是有价值的参与变成垃圾信息的转折点。

修复方案是一份明确的能力清单。

artifact:
  name: Living Context Engine

implemented:
  - deterministic_file_ingestion
  - explicit_state_classification
  - sqlite_persistence
  - source_path_provenance
  - source_line_provenance
  - content_hash_provenance
  - timeline
  - source_linked_context_pack

not_implemented:
  - semantic_vector_retrieval
  - autonomous_memory
  - agent_orchestration
  - distributed_consensus
  - transactional_external_side_effects

这就成了一个证据边界。 生成的贡献可以做出属于 implemented 集合的声明。 不得悄悄越界到 not_implemented 集合。

这使得制品匹配更加可信。

Contribution value and artifact fit are not the same score

这个区分经过验证是至关重要的。 对于每个候选对象，至少计算两个独立分数：

• 我们能否实质性改善这个讨论？
• 我们的实际制品是否在这里实现了有用的原语？

不要把它们合并成一个单一的"相关性分数"。

讨论可能很有价值，即使你的项目没有任何有用的贡献。 帮助，但不要链接。

同样，你的制品可能完美匹配某个主题，但帖子可能已经被解决或饱和到无可救药。

一个简单的策略表如下：

contribution_value	artifact_fit	action
high	high	draft + human review
high	low	draft (help without link)
low	high	skip (saturated/wrong thread)
low	low	skip

这个分离防止了大量不良行为。

找到每一个我可以提及仓库的对话。 找到我可以做出有用贡献的对话，然后独立判断制品是否属于那次贡献。

Keywords are useful for discovery, not understanding

关键词搜索是一个完全合理的第一遍发现机制。 但它不应该成为系统的持久思维模型。

考虑这五个问题描述：

"state prompt doesn't update"

"history index hides sessions"

"handoff contains stale assumptions"

"busy rejection becomes permanent error"

"client transcript overwrites canonical message"

在字符串层面，它们看起来毫无关联。 在系统层面，其中几个可以规范化为相同的深层结构：

AUTHORITATIVE STATE
        ↓
DERIVED PROJECTION
        ↓
PROJECTION BECOMES STALE OR WRONG
        ↓
NO INVALIDATION OR RECONCILIATION RULE

这有用得多。

搜索"state prompt"时， 系统可以学习：

寻找可能偏离其权威源的派生状态。

现在知识可以在仓库、框架、产品甚至平台之间转移。

The real reusable unit is an engineering pattern

最终，高质量的重复贡献应该成为持久模式。

pattern:
  id: stale-derived-projection

  invariant:
    authoritative_source: required
    derived_projection: allowed
    projection_version: required
    invalidation_on_source_change: required
    reconstruction: preferred

  prior_successes:
    - llama_index#22248
    - codex#19822
    - paseo#2889
    - mastra#20836

这改变了系统的性质。

它不再构建一个：

我们回复过的好的 GitHub Issue 数据库。

它在构建一个：

反复帮助诊断真实问题的工程不变量库。

这更具可迁移性。 新的信号可以根据其底层失败模式而不是其词汇来匹配先前的模式。

A cleaner architecture

引擎可以分离为八个模块：

1. adapters/
   github.py
   reddit.py
   discourse.py
   ...

2. normalization/
   canonical_signal.py

3. artifact/
   capability_manifest.py
   evidence_boundary.py

4. analysis/
   problem_extractor.py
   existing_solution_detector.py
   missing_primitive.py

5. scoring/
   signal_score.py
   contribution_score.py
   artifact_fit.py
   saturation.py
   spam_risk.py

6. generation/
   contribution.py
   contextual_reference.py

7. policy/
   human_gate.py
   skip_rules.py

8. feedback/
   replies.py
   reactions.py
   conversions.py
   policy_update.py

这种分解创造了有用的职责分离。

• 适配器理解平台。
• 规范化理解结构。
• 分析理解问题。
• 制品清单理解真相。
• 评分理解机会。
• 生成提出贡献方案。
• 策略决定是否适合发布。
• 反馈更新未来目标定位。

The human gate should remain explicit

即使系统变得更强大，我仍会保留这一个设计决策：

publishing:
  auto_publish: false
  require_human_review: true

这个系统最高风险的部分不是找到信号。 而是在别人的社区中进行互动。 评分 bug 可能产生糟糕的候选。 生成 bug 可能产生夸大的声明。 规范化 bug 可能忽略这个问题在三条回复前已经被解决了。

人类审查相比于损害信任而言成本很低。 自动化可以做昂贵的工作： 最终发布决策可以保持由人来做。

Feedback should improve targeting, not just copywriting

一旦贡献发布，引擎应该观察发生了什么。

• 维护者参与了吗？
• 对话在技术层面继续了吗？
• 有人检查了仓库吗？
• 候选对象产生了 Issue、Star 或 PR 吗？
• 哪些问题模式反复产生了有意义的互动？

那些反馈应该更新目标策略。

"包含这个短语的意见表现良好。"

"低饱和度、维护者可见的讨论中，未解决的 authoritative-state / derived-projection 失败
历来产生了有用的技术参与。"

这是一个更健康的优化目标。

From outreach automation to contribution intelligence

架构上的转变用词很小但影响很大。

不要把系统建模为：

GitHub 搜索
→ Issue 过滤器
→ 评论生成器
→ 仓库链接

而是这样：

Signal
→ Normalized Problem
→ Engineering Invariant
→ Contribution Gap
→ Artifact Correspondence
→ Human-Reviewed Contribution
→ Feedback

然后让数据源可替换。

platform = adapter

repo / community = target configuration

project = capability manifest

objective = policy

intelligence = platform-independent

这样，这个系统就不再是一个 GitHub 外展脚本。 它变成了一个贡献智能引擎：一个可复用的系统，用于寻找未解决的技术信号，理解底层工程问题，判断是否存在真正有用的东西可以添加，然后才决定制品是否属于那次对话。

这是一个更有趣的系统来构建。