LazyMind v0.2 正式发布，围绕任务执行中最容易失控的几个环节完成了 14 项更新：开始前先对齐要求，执行中保留过程，完成后交付可编辑产物，并把人的修改沉淀为下一次任务的经验。
这组变化的重点不只是“多了哪些功能”，而是把一次性的任务执行，逐步变成可以检查、修改和复用的工作流。
从结果导向转向过程可见
很多自动化任务的问题并不在最终结果，而在结果生成之前发生了什么：需求是否理解一致，执行过程中是否遗漏了约束，用户修改后系统是否知道哪些地方需要改进。
LazyMind v0.2 的更新可以归纳为一条完整链路：
- 任务开始前对齐要求：明确目标、输入、输出格式和限制条件。
- 任务执行中保留过程：让关键步骤、判断依据和中间产物可追踪。
- 任务完成后交付可编辑产物：用户拿到的不只是一次性结果，还能继续修改和使用。
- 把修改沉淀为经验：人的反馈不再只影响当前任务，也能服务后续任务。
这意味着系统不应只回答“做完了吗”，还要回答“依据什么做的”“中间发生了什么”和“下一次如何做得更好”。
14 项更新背后的工作方式
从摘要披露的信息看，v0.2 没有把重点放在单点能力的堆叠上，而是围绕任务生命周期进行补全。这样的设计对实际使用很重要，因为真实任务通常不是一次生成、一次验收就结束。
开始前：把隐含要求变成显式约束
用户常常会把格式、受众、语气、边界条件和验收标准分散在多轮对话里。如果这些要求没有在执行前被整理出来，后续就容易出现“看起来完成了，但并不是用户要的结果”。
可以在任务启动时生成一份简短的任务契约：
# task-contract.yaml
name: release-note
objective: 生成一份面向开发者的版本更新说明
inputs:
- release-summary.md
constraints:
language: zh-CN
format: markdown
include:
- 变化说明
- 可复制示例
- 风险与采用建议
exclude:
- 未确认的性能数据
acceptance:
- 标题明确
- 内容可以被用户继续编辑
- 所有事实都能追溯到输入或明确标注为实践建议
这个文件是示例性的任务契约，字段可以根据实际系统调整。关键不在 YAML 的具体名字，而在于让目标和验收条件进入执行上下文，而不是依赖操作者临时记忆。
执行中：保留足够的过程信息
过程记录不等于把所有日志全部暴露给用户。更实用的做法是保留可解释的事件，例如：
- 已读取哪些输入；
- 识别出哪些硬性约束；
- 生成了哪些中间产物；
- 哪些步骤需要人工确认；
- 最终交付物由哪些步骤生成。
可以用一个最小事件模型记录任务轨迹。下面的 Python 示例不依赖第三方库，保存为 workflow.py 后即可运行：
from dataclasses import dataclass, asdict
from datetime import datetime, timezone
import json
from pathlib import Path
@dataclass
class Event:
task_id: str
name: str
detail: str
timestamp: str
def record(task_id: str, name: str, detail: str, events: list[Event]) -> None:
events.append(Event(
task_id=task_id,
name=name,
detail=detail,
timestamp=datetime.now(timezone.utc).isoformat(),
))
def run_task(task_id: str, output_dir: str = "artifacts") -> None:
events: list[Event] = []
record(task_id, "requirements_aligned", "确认输出格式、语言和验收条件", events)
record(task_id, "input_loaded", "读取任务输入", events)
record(task_id, "draft_created", "生成可编辑初稿", events)
record(task_id, "delivery_ready", "输出 Markdown 和过程记录", events)
target = Path(output_dir)
target.mkdir(parents=True, exist_ok=True)
(target / f"{task_id}.md").write_text(
"# 可编辑任务产物\n\n这里替换为实际生成内容。\n",
encoding="utf-8",
)
(target / f"{task_id}.events.json").write_text(
json.dumps([asdict(event) for event in events], ensure_ascii=False, indent=2),
encoding="utf-8",
)
if __name__ == "__main__":
run_task("demo-task")
print("Generated artifacts/demo-task.md and artifacts/demo-task.events.json")
运行命令：
python workflow.py
这个示例只展示一种实践方式，并不代表 LazyMind v0.2 的内部实现。它体现的是同一个工程原则：任务结果和任务过程应该分别保存，方便审查、重试、修改和后续分析。
交付可编辑产物，而不是封闭结果
“可编辑”会直接影响自动化系统的使用边界。一个只能复制粘贴的最终答案，适合快速问答；一个结构清晰、保留原始内容并允许局部修改的产物，才更适合文档、代码、计划和持续协作。
可编辑交付至少应考虑三个层面：
- 格式可编辑：优先选择 Markdown、JSON、YAML 或其他用户已有工具可以处理的格式；
- 结构可编辑：标题、段落、配置项和步骤应有明确边界，避免所有内容挤成一段文本；
- 来源可追踪：用户修改时，能够知道修改的是原始要求、生成内容还是人工补充。
这也解释了为什么过程记录与可编辑产物需要一起设计。用户修改结果之后，如果系统无法区分“模型生成内容”和“用户最终选择”，就很难可靠地学习反馈。
把人的修改变成下一次任务的经验
v0.2 摘要中最值得关注的部分，是把人的修改沉淀为下一次任务的经验。这里的“经验”不应简单理解为无限追加的历史文本，更适合被整理为可检索、可验证的规则或偏好，例如：
{
"scope": "release-note",
"preference": "面向开发者时提供可复制的命令或代码示例",
"reason": "减少读者从概念到实践的转换成本",
"source": "user_edit",
"confidence": 0.9
}
在实际落地时，可以给经验增加范围、来源和置信度，避免某一次临时修改被错误应用到所有任务。经验写入流程也应有边界：
- 识别用户修改了什么；
- 判断修改是否具有可复用性；
- 记录适用任务类型和来源；
- 在下一次任务开始前检索；
- 让用户能够查看、修改或删除这条经验。
这类设计把人的参与从“最后帮忙改稿”提升为“持续校准任务系统”。但它也带来新的风险：错误偏好可能被重复传播，过时规则可能影响新任务，敏感内容也不应被自动写入长期经验库。因此，经验系统需要版本、来源和撤销机制。
采用时可以检查什么
LazyMind v0.2 适合按照任务风险逐步采用，而不是一次性把所有流程都自动化。可以从低风险、输出边界清晰的任务开始，例如生成文档初稿、整理变更记录或创建结构化计划。
上线前建议检查：
- 是否能在任务开始时明确目标和验收条件；
- 是否能查看关键执行过程，而不是只有最终文本；
- 交付物是否可以被用户直接编辑；
- 用户修改是否能与模型原始输出区分；
- 经验是否具备适用范围、来源和撤销能力；
- 失败任务是否可以重试，而不必从头手工整理；
- 敏感信息是否会进入过程记录或长期经验库。
LazyMind v0.2 的方向很清楚：任务自动化不应只追求更快地产生结果，还要让要求对齐、过程保留、产物编辑和经验复用形成闭环。对于开发团队而言，真正值得验证的指标也不只是生成速度，而是返工次数、人工修改成本，以及下一次同类任务是否确实变得更稳定。