AI编程 on Coder_Studio

从 MSE 到交叉熵：一文搞懂损失函数

Sun, 21 Jun 2026 11:48:50 +0000

什么是损失函数？

机器学习模型究竟依靠什么完成"学习"？

它凭什么判断自身的表现是否达标、又该在哪些方面做出改进？

我们可以通过一个类比来理解——学生在完成课后作业时，老师会给出一个分数。无论是80分、90分还是不及格，学生都能通过这个分数发现自己哪里掌握得不够牢固，并据此调整后续的学习策略，争取下一次取得更好的成绩。

机器学习的模型同样具备类似的反馈机制，这个机制的名称就叫——损失函数。

损失函数在机器学习中占据着比较重要的位置。

如果无法理解损失函数的工作原理，就很难真正搞清楚模型是如何完成训练的。

因此，想要真正掌握机器学习的核心原理，损失函数是一个必须深入理解的基础概念。

从数学角度来讲，损失函数是用于衡量模型预测输出与真实标签之间差异的一种量化方法。

设想这样一个场景：

一个气象预报员，预测明天的气温是20℃，而实际观测值是22℃。

预测值与真实值之间的偏差是多少？

最直接的计算方式是用 20 减去 22 得到 -2，偏差为2℃。

但这里出现了一个问题：

如果有100次预报记录，将正偏差和负偏差直接相加会导致它们相互抵消，最终累加结果可能为零——意味着"零误差"，显然这与现实情况是不符的。

解决这一问题的方法是对每次偏差进行平方处理，使所有数值都变为正数，然后求取平均值。这就是"均方误差"（Mean Squared Error，简称 MSE）。

由此可见，损失函数的本质是一个"差距量化器"——它明确告诉模型：你的预测出现了偏差，偏差量为多少，需要做出调整。

然而，这种差距信号如何真正转化为模型的改进能力呢？

关键在于梯度。

具体而言，我们可以通过反向传播算法，利用链式法则逐层计算损失函数对各参数的梯度，得到的梯度方向指示了参数应该增大还是减小，梯度的大小则给出了调整的幅度。

模型根据这些梯度信息更新自身参数，持续缩小与真实值之间的距离。

这一优化过程被称为梯度下降。

需要明确的一个核心认知是：

驱动模型学习的根本动力，来源于损失函数所提供的梯度信号。

如果没有损失函数，就不会有梯度；

没有梯度，模型就只能在参数空间中盲目搜索。

因此，损失函数决定了模型能否有效学习，是整个学习过程的灵魂所在。

什么样的损失函数才算合格？

第一，可导性。

损失函数最好能够计算梯度，或者在不可导点存在次梯度（Subgradient），从而支持梯度优化算法。

第二，单调性。

模型的预测越接近真实值，损失值应当越小；

预测偏离真实值越远，损失值应当越大。

只有满足这一性质，模型才能形成明确的优化方向感，持续向最优解靠近。

第三，良好的优化性质。

理想情况下，损失函数及其对应优化目标具有良好的优化性质，能够帮助模型更稳定地收敛到低损失区域。

第四，计算高效。

在大规模数据集训练场景中，损失函数需要被频繁计算，因此计算效率十分重要。

在这四项特性中，前两项属于硬性约束，后两项则是理想层面的加分项。

具体损失函数分析

均方误差（MSE）

MSE 的全称为 Mean Squared Error，逐词拆解：Mean 表示"平均"，Squared 表示"平方"，Error 表示"误差"。

组合起来的含义即——误差平方的平均值。

其计算流程分为四个步骤：

对每个样本分别计算预测值与真实值之间的差值（也称为残差）。
对每个残差执行平方运算。
将所有平方后的残差累加求和。
除以样本总数 N，得到平均值。

为什么不直接使用残差的绝对值，而一定要选择平方？

第一个理由：消除符号干扰。

假设模型对样本 A 的预测偏高了 5 个单位，对样本 B 的预测偏低了 5 个单位。如果直接将两者相加，5 + (-5) = 0，表面上看起来误差为零，但实际上模型的两次预测都是错误的。

经过平方运算后，5² = 25，(-5)² = 25，两项均为正数相加，真实误差便无法被掩盖。

第二个理由：放大较大误差。

假设有三个样本的绝对误差分别为 1、2、3。

在不平方的情况下，误差总和为 6；

而经过平方后，1 + 4 + 9 = 14，其中误差为 3 的样本贡献了 9，占总损失的比重超过六成。

这说明平方机制天然地让模型更加重视那些预测严重失准的样本，尽量避免出现"离谱的错误"，这通常与实际需求相一致。

第三个理由：求导运算友好。

平方函数在其定义域内处处可导，导数形式为线性表达式 2x，结构简洁，使得梯度下降算法的运行非常顺畅。

第四个理由：拥有深厚的统计学根基。

在正态分布假设下，MSE 与最大似然估计在数学上是等价的。

它并非一种拍脑袋想出来的启发式技巧，而是建立在严格的概率论基础之上的。

MSE 的优势与局限

优势：

计算极为简洁——仅需减法、平方、加法和除法四步运算，即便面对千万级甚至亿级规模的数据也能快速处理。

在整个定义域内处处可导，梯度形式简洁干净，不存在任何断点或奇点来阻碍优化过程。

数学性质优良，许多优化算法的理论分析都建立在 MSE 这类凸函数的框架之上。

局限：

最突出的短板是对异常值（离群点）极度敏感。

平方的放大效应意味着一个极端异常值可能主导整个损失函数的值。

例如假设有 10 个样本的偏差均为 1，另有 1 个样本的偏差为 10。

前 10 个样本各自贡献 1，合计 10；

而异常样本贡献了 100，占总损失的约 91%。

模型因此可能被这一个异常样本带偏方向，从而忽略了大多数正常数据的分布特征。

另一个问题是量纲失真。

原始数据如果分布在 0 到 100 之间，MSE 的值域可能膨胀到 0 到 10000，损失值本身的直观含义变得模糊。

适用场景：

回归任务的首选方案——凡是预测连续型数值（如房价、气温、销量等），MSE 通常是最自然且最常用的选择。

但如果数据中存在较多异常值，建议考虑 MAE（平均绝对误差）或 Huber Loss，它们对噪声数据具有更强的鲁棒性。

梯度下降的训练循环

利用 MSE 的梯度来驱动模型参数更新，每一轮迭代包含以下四个步骤：

前向传播：使用当前参数对输入数据进行预测。
计算损失：通过 MSE 公式量化预测值与真实标签之间的差距。
反向传播：沿计算图从输出层向输入层逐层回溯，依次计算每个参数的梯度，明确每个参数应该朝哪个方向调整、调整的幅度有多大。
参数更新：沿着梯度的反方向对参数值进行微调——梯度为正值时减小参数，为负值时增大参数。

重复执行上述流程 50 次（或更多轮），模型便会在损失曲面上逐步滑动，不断逼近最优解。

交叉熵：分类问题的核心损失函数

接下来介绍第二个重要的损失函数——交叉熵（Cross Entropy），它是分类任务中最常用的损失函数。

设想这样一个应用场景：

向模型输入一张图片，要求它判断图片中的动物是猫、狗还是鸟。

有人可能会认为，模型直接输出一个整数编码即可——0 代表猫，1 代表狗，2 代表鸟，然后取最大值的对应类别就行了。

这种思路在逻辑上看似合理，但存在一个缺陷：

模型对自己的预测结果有多大把握？

这种确定性完全无法从单一整数编码中获知。

更为合理的方式是让模型输出一个概率向量。

例如：猫 0.7、狗 0.2、鸟 0.1，三个概率值之和为 1，构成一个完整的概率分布。

通过这种方式，我们不仅获得了模型的预测结果，还获得了衡量模型"自信程度"的依据。

在很多实际应用场景中，这种置信度信息至关重要。

例如医疗影像诊断：

模型 A 判定为恶性肿瘤，置信度 0.95。

模型 B 判定为恶性肿瘤，置信度 0.52。

虽然两者结论一致，但前者的预测可信度明显更高，因此更值得进一步关注。

那么问题就来了：

如何衡量模型输出的概率分布与真实标签之间的差异？

这就是交叉熵函数所要解决的问题。

交叉熵到底在计算什么？

交叉熵的核心思想其实非常简单：

如果模型把真实答案的概率预测得越高，那么损失就应该越小；

如果模型把真实答案的概率预测得越低，那么损失就应该越大。

例如有一个三分类任务：

真实答案是：

猫 = 1
狗 = 0
鸟 = 0

模型 A 的预测结果为：

猫：0.90
狗：0.05
鸟：0.05

由于模型给正确类别“猫”分配了 90% 的概率，说明模型非常有把握地预测正确，此时交叉熵损失会非常小。

而模型 B 的预测结果为：

猫：0.01
狗：0.98
鸟：0.01

虽然三个概率之和同样为 1，但模型几乎把全部概率都给了错误类别“狗”。

这意味着模型不仅预测错误，而且错得非常自信。

对于这种情况，交叉熵会给予极大的惩罚。

因此可以把交叉熵理解为一种专门衡量“预测概率质量”的损失函数。

它不仅关心模型有没有预测正确，更关心模型到底有多大的把握。

预测正确且越自信，损失越小；

预测错误且越自信，损失越大。

正因为这种特性，交叉熵能够为分类模型提供更加清晰有效的优化方向，因此成为分类任务中最主流的损失函数。

MSE 与交叉熵的核心差异

维度	MSE	交叉熵
适用任务	回归（预测连续值）	分类（预测离散类别）
输出形式	实数（如 3.5、-2.1）	概率（0~1 之间的值）
梯度特性	梯度受平方项影响较大，对异常敏感	梯度与误差成线性关系，传播更平稳
收敛行为	回归任务上收敛稳定	分类任务上收敛更快、更稳定

如何选择损失函数

判断任务类型

如果输出为连续数值 → 回归问题，如果输出为类别标签 → 分类问题。

回归任务看数据质量

如果数据包含较多异常值 → 选择 MAE 或 Huber Loss

如果数据较为干净、近似正态分布 → 选择 MSE

分类任务看类别数量

如果仅有两个类别 → 二元交叉熵（Binary Cross Entropy）

如果两个以上类别 → 多元分类交叉熵（Categorical Cross Entropy）

初学者常犯的三个错误

用 MSE 做分类任务。

这是新手最常犯的错误。

因为在分类任务中，当分类模型使用 sigmoid 或 softmax 输出概率时，如果再配合 MSE 作为损失函数，梯度在饱和区域会迅速衰减，导致训练速度明显变慢。

用交叉熵做回归任务。

交叉熵要求输出为合法的概率分布（非负且和为 1），回归任务的输出为任意实数，计算框架通常会直接报错；

即便绕过了框架检查，梯度也会完全失效，模型无法学到任何有效信息。

只监控训练损失，忽视验证损失。

许多初学者在训练过程中仅关注训练集损失持续下降这一现象便感到满意，却忽略了验证集损失可能已经开始反弹——这标志着过拟合正在发生。

正确的方法是同时监控训练损失和验证损失两条曲线，当验证损失不再下降甚至开始上升时，即使训练损失仍在降低，也应当停止训练或引入正则化手段来抑制过拟合。

Claude Code 免费接入讯飞星辰 Qwen3.6-35B-A3B 模型，白嫖攻略来了！

Tue, 09 Jun 2026 00:55:09 +0000

限时免费到6月30日，手慢无！

最近讯飞星辰 MaaS 平台可以免费领取Qwen3.6-35B-A3B、Qwen3.5-35B-A3B两个 Qwen 系列模型的调用权益，这意味着你可以零成本把这个强大的模型接入到 Claude Code 中，享受免费的高质量代码生成和智能编程体验。

本文就来手把手教你，如何把Qwen3.6-35B-A3B模型接入 Claude Code。

接入流程

1.在讯飞星辰平台找到模型

登录讯飞星辰 MaaS 平台，进入【模型集市】，找到 Qwen3.6-35B-A3B 模型卡片，点击【API调用】按钮。

2.创建 API 服务

在 API 调用页面，填写模型服务 API 名称（例如 Chatxunfei），选择要授权的应用。

重点来了——计费方式显示输入和输出费用均为 0 元/百万 tokens，免费有效期到 6月30日，7月1日10点后转为后付费。

所以趁现在赶紧用起来！

3.创建应用（如尚未创建）

如果你还没有应用，需要先前往讯飞开放平台创建一个应用。

填写应用名称、分类和功能描述，提交即可。

4.获取modelId和APIKey

创建完成后，在推理服务页面可以看到你部署的服务信息，包括：

modelId：xopqwen36v35b
APIKey：用于身份认证

5.在CC Switch 中配置模型

先进入CC Switch的网址： https://github.com/farion1231/cc-switch/releases/tag/v3.16.0

下载好CC Switch。

如果访问Github有困难，也可以通过以下方式下载

链接：https://pan.quark.cn/s/46e3a4a215bd

打开 CC Switch，添加新供应商：

参数填写可参考：

配置完成后，CC Switch 会自动将 Claude Code 的请求路由到讯飞星辰的 API 端点。

6.在 Claude Code 中测试

配置完成后，打开 Claude Code，测试一下：

如上图所示模型显示为：xopqwen36v35b，而且正常返回了结果，说明接入成功。

让 AI Agent 跨会话接住工作：一场对照实验

Sun, 07 Jun 2026 14:38:00 +0000

当 AI 编程助手越来越强大，一个关键问题浮出水面：它能接住别人（或昨天的自己）没干完的活吗？

问题的起源

真实开发不是一次会话就干完的。你昨天写了一半，今天开新会话，agent 需要从仓库状态里搞清楚：

项目是干什么的？
怎么启动？
哪些功能已经做了？
哪些还没做？
下一个该做什么？

如果 agent 要靠"猜"来回答这些问题，那它本质上是在重新发现已经存在的信息。这既浪费时间，又容易出错。

实验设计

我们在同一个 Electron 知识库应用上做了两组对照实验，任务完全一致——实现三个功能：

功能	描述
kb-005 文档导入	从本地导入 .txt/.md 文件
kb-006 文档详情视图	点击文档查看完整内容
kb-007 文档持久化	重启后文档仍在

两组实验的区别只在于：仓库里有没有"可读的上下文"。

实验组 A：弱 Harness（Baseline）

仓库里有什么？
├── main.js          # 代码
├── preload.js       # 代码
├── index.html       # 代码
├── renderer.js      # 代码
├── package.json     # 依赖
└── task-prompt.md   # 任务描述

仓库里没有什么？
✗ ARCHITECTURE.md    — 没有架构文档
✗ PRODUCT.md         — 没有产品文档
✗ session-handoff.md — 没有交接文件
✗ feature_list.json  — 有，但 agent 不知道要先读

会话 A：agent 完成了文档导入（kb-005），然后被中断。没有写任何交接文件。

会话 B：开全新会话，只说了一句：

继续开发。

发生了什么？

┌─────────────────────────────────────────────────────────┐
│  会话 B 的探索过程                                       │
│                                                         │
│  Step 1: 读 main.js          → 哦，这是 Electron 应用    │
│  Step 2: 读 package.json     → 启动命令是 npm start      │
│  Step 3: 读 preload.js       → 用 contextBridge 暴露 API │
│  Step 4: 读 index.html       → 这是 UI 布局              │
│  Step 5: 读 renderer.js      → 哦，已经有一个导入按钮了   │
│  Step 6: 读 feature_list.json → kb-001~004 已完成         │
│  Step 7: 对比代码差异        → 所以 kb-005 做完了？       │
│  Step 8: 终于开始写代码...    → 但已经过去很久了          │
└─────────────────────────────────────────────────────────┘

核心问题： agent 花了大量时间在重新发现——项目结构、启动方式、数据流、已完成的功能。这些都是会话 A 已经知道的信息。

实验组 B：强 Harness（Improved）

仓库里有什么？
├── ARCHITECTURE.md    # 项目架构、数据流、IPC 接口清单
├── PRODUCT.md         # 产品功能范围和当前阶段目标
├── AGENTS.md          # 启动命令、工作规则
├── feature_list.json  # 功能状态（已更新）
├── session-handoff.md # 本轮做了什么、没做什么、下一步
├── main.js            # 代码
├── preload.js         # 代码
├── index.html         # 代码
├── renderer.js        # 代码
└── task-prompt.md     # 任务描述

会话 A：同样完成了文档导入（kb-005），中断前更新了 session-handoff.md 和 feature_list.json。

会话 B 的 session-handoff.md：

## 本轮会话做了什么
- kb-005 文档导入：已完成并验证通过

## 没做什么（遗留功能）
- kb-006 文档详情视图：未开始
- kb-007 文档持久化：未开始

## 下一步
1. 实现 kb-006：文档详情视图
2. 实现 kb-007：文档持久化

会话 B：开全新会话，发送：

1
2

请先阅读 session-handoff.md、feature_list.json、ARCHITECTURE.md、PRODUCT.md，
然后继续开发未完成的功能。

发生了什么？

┌─────────────────────────────────────────────────────────┐
│  会话 B 的探索过程                                       │
│                                                         │
│  Step 1: 读 session-handoff.md  → 知道了！kb-005 已完成  │
│                                   下一步是 kb-006        │
│  Step 2: 读 feature_list.json   → 确认功能状态           │
│  Step 3: 读 ARCHITECTURE.md     → 确认项目结构           │
│  Step 4: 直接开始写代码！        → 零浪费                  │
└─────────────────────────────────────────────────────────┘

数据对比

                    弱 Harness          强 Harness
                    ─────────          ─────────
接手所需文件数      ████████ 6-8       ██ 2-3
重新发现次数        ██████ 6+          ░ 0~1
重复工作比例        ██████ ~30%        ░ ~5%
上下文理解准确度    可能有偏差          准确无误

关键洞察

1. 代码不是文档

代码能告诉你"怎么做"，但很难告诉你"做了什么、为什么没做、下一步做什么"。一个 500 行的 main.js 不会告诉你 kb-006 还没开始——agent 必须自己推断，而推断经常出错。

2. 交接文件是"会话的 checkpoint"

session-handoff.md 就像一个游戏存档。没有它，每次新会话都相当于从第一关重打。有了它，agent 可以直接从上次中断的地方继续。

3. 最重要的三行信息

1
2
3

做了什么：kb-005 文档导入 ✓
没做什么：kb-006 文档详情、kb-007 文档持久化
下一步：从 kb-006 开始

就这三行，节省了 agent 6+ 步探索。

4. 一份大指令文件不够

如果把所有规则塞进一个巨大的 system prompt，agent 会"迷失在细节里"。仓库中的多个小文件（ARCHITECTURE.md、PRODUCT.md、session-handoff.md）各司其职，按需读取，效果更好。

结论

仓库必须是唯一的事实来源。

不是某个 agent 的记忆，不是聊天记录，不是某个巨大的指令文件——而是仓库里的结构化文档。

当你的 agent 能在一分钟内搞清"这是哪、到哪了、下一步去哪"，你就有了一个真正可交接的 AI 工作流。

只写提示词让 agent 做，和定好规则再让它做，差多少

Sun, 07 Jun 2026 08:21:47 +0000

实验背景

AI Agent 写代码越来越强，但"强"不等于"可靠"。同样的模型、同样的提示词，为什么有时候一次就过，有时候反复翻车？答案往往不在模型本身，而在你给它的规则和约束。

这个实验用 Electron 搭建一个知识库应用壳子，跑两次：

弱 Harness：只给一段提示词，什么都不准备
强 Harness：提前准备好 AGENTS.md、feature_list.json、claude-progress.md，用结构化方式告诉 Agent 该干什么、怎么验证、什么时候算做完

任务定义

用 Electron 做一个知识库应用，包含四个核心功能：

编号	功能	要求
kb-001	窗口启动	`npm start` 后 Electron 窗口正常打开
kb-002	左侧文档列表	左侧面板显示文档列表区域
kb-003	右侧问答面板	右侧面板包含输入框和对话区域
kb-004	本地数据目录	应用启动时创建数据目录，包含 documents/、qa/ 子目录

Harness 是什么

Harness 不是代码，是一套告诉 Agent 怎么干活、怎么验证、什么时候算做完的规则文件。这个实验用的 Harness 核心包含三个文件，实际仓库中还会配合 init.sh 等辅助脚本：

AGENTS.md

定义 Agent 的核心行为规则：

- 一次只做一个功能
- 实现后必须运行 npm start 验证
- 不要因为"代码已经写了"就把功能标记为完成
- 验证证据记录在 feature_list.json 或 claude-progress.md
- 一个功能只有在目标行为已实现、npm start 成功、证据已记录才算完成

feature_list.json

每个功能的唯一事实来源，包含验收标准、证据槽位：

{
  "id": "kb-001",
  "title": "窗口启动",
  "status": "not_started",
  "verification": [
    "运行 npm start",
    "确认 Electron 窗口成功打开",
    "确认窗口标题显示应用名称"
  ],
  "evidence": []
}

claude-progress.md

会话进度日志，记录当前状态、已完成功能、已知风险、下一步动作。

第一次实验：弱 Harness

分支：p01-baseline

提示词：

用 Electron 做一个知识库应用，窗口左边是文档列表区域，右边是问答面板区域，应用需要创建并使用本地数据目录。

仓库状态：空的 package.json，没有 AGENTS.md，没有 feature_list.json

过程

Agent 自由发挥，一次性完成了所有四个功能。代码质量很好，UI 布局清晰，IPC 通信正确。

结果

功能	状态	备注
kb-001 窗口启动	✅ 完成	一次通过
kb-002 文档列表	✅ 完成	左侧 300px 面板
kb-003 问答面板	✅ 完成	右侧 flex 面板
kb-004 数据目录	✅ 完成	目录结构正确

应用截图

弱 Harness 的问题

虽然任务完成了，但存在以下问题：

没有验证证据：功能完成了，但没有记录"怎么验证的"、“验证结果是什么”
没有风险记录：遇到 EPERM 权限问题，但没有记录到任何地方
没有可接续性：下一轮会话必须重新理解代码，无法从上次中断的地方继续
没有完成定义：Agent 不知道"什么时候算做完"，全靠自己判断

第二次实验：强 Harness

分支：p01-improved

提示词：完全相同

仓库状态：AGENTS.md、CLAUDE.md、init.sh、feature_list.json、claude-progress.md 已就位

过程

Agent 严格按照 AGENTS.md 的流程执行：

读取 claude-progress.md → 确认 kb-001 为最高优先级
读取 feature_list.json → 获取 4 个功能的验收标准
发现状态不一致 → feature_list.json 中功能标为 passing，但代码已清空，先修复基础状态
逐功能实现 → 每完成一个功能，运行验证，记录证据
遇到 Blocker → Windows EPERM 阻止在 userData 目录创建子目录，按规则在窄范围修复
更新 Harness 文件 → 所有功能标记为 passing，记录风险

强 Harness 的行为差异

以下是 Agent 在关键决策点上的行为重构示意（非原始逐字日志）：

# Agent 读到的不一致状态时的反应：
"feature_list.json 中所有功能标为 passing，但 main.js 不存在。
 这违反了 AGENTS.md 规则。先修复基础状态。"

# 遇到 Blocker 时的反应：
"EPERM 权限错误。
 AGENTS.md 规则：窄范围修复，不扩大到其他功能。
 将数据目录路径改为项目根目录，功能行为不变。"

# 完成后的动作：
"更新 feature_list.json：
  - status → passing
  - evidence 字段填入验证证据
 更新 claude-progress.md：
  - 记录风险（EPERM）
  - 记录下一步动作"

结果

功能	状态	证据
kb-001 窗口启动	✅ passing	BrowserWindow 创建，index.html 加载
kb-002 文档列表	✅ passing	#left-panel 300px，border-right 边界
kb-003 问答面板	✅ passing	#right-panel flex:1，含输入交互
kb-004 数据目录	✅ passing	data/documents/ + data/qa/ 已创建

应用截图

对比分析

核心指标

指标	弱 Harness	强 Harness	备注
首次成功启动	一次通过	三次	强 Harness 因主动发现并修复 EPERM 权限问题而多次重启，非代码质量问题
遗漏项	无	无
过早停止	否	否
验证证据	无	feature_list.json 结构化证据
风险记录	无	claude-progress.md 记录 EPERM
可接续性	需重新理解代码	读 claude-progress.md 即可
状态一致性检查	无	主动发现并修复不一致

深层差异

这个实验里，两个版本最终都完成了任务，UI 效果完全一样。但这不代表 Harness 没用——恰恰相反，简单的任务看不出 Harness 的价值，复杂的任务看不出 Harness 的边界。

真正体现差异的地方：

1. 状态一致性检查

强 Harness 下，Agent 发现 feature_list.json 中功能标记为 “passing” 但代码不存在时，主动停下来修复基础状态。弱 Harness 下，Agent 不会注意到这种不一致，会在坏的起点上继续叠加代码。

2. Blocker 处理策略

强 Harness 下，遇到 EPERM 权限错误时，AGENTS.md 的"窄范围修复"规则防止了 Agent 去修改其他无关代码。弱 Harness 下，Agent 可能过度修改，也可能直接放弃。

3. 证据链

强 Harness 下，feature_list.json 每个功能都有 evidence 字段记录了验证证据。claude-progress.md 记录了风险和下一步动作。下一轮会话直接读这两个文件就能接续，不需要重新理解代码。

4. 完成定义

强 Harness 有明确的完成定义：目标行为实现 + npm start 成功 + 证据记录在案。弱 Harness 下，Agent 自己判断"差不多完成了"，没有外部验证标准。

关键结论

1. 简单任务中，Harness 的价值是"防御性"的

这次实验任务简单，两个版本都完成了。但 Harness 的价值在于防止意外——状态不一致、权限错误、风险遗漏，这些在简单任务中可能不致命，但在复杂任务中会累积成灾难。

2. Harness 解决的是"接续"问题，不是"完成"问题

Agent 的单次执行能力很强，但多轮会话之间的接续是短板。Harness 通过 feature_list.json（状态）和 claude-progress.md（上下文）让下一轮会话能无缝接续。

3. 规则的价值在于"约束行为"，不在于"提升质量"

Harness 不会让 Agent 写出更好的代码，但会让 Agent 的行为更可预测、更规范。feature_list.json 的验收标准不是为了让代码更好，而是为了让"完成"有一个客观的判断标准。

4. 好的 Harness 是"最小可行约束"

Harness 不是越多越好。AGENTS.md 的核心规则只有几条：一次一个功能、必须验证、证据必须记录。过多的规则会让 Agent 过度遵循流程，反而降低效率。