第 1 章：先定义完成——需求、边界与验收标准

动手前先定义“完成”

命令行工具的历史可以追溯到早期分时系统和 Unix。它强调一条至今仍然实用的原则：一个程序做好一件事，并能被清晰、稳定地调用。我们不需要模仿复杂工具，但要继承这种可预测性。

这个项目的成功标准不是“代码能编译”，而是用户关闭终端后重新打开，仍能看到之前保存的任务，并且每个错误都有可理解的提示。

写出四条用户故事

把需求写成用户真正要完成的动作：

1. 我想添加一条任务，稍后不会忘记。
2. 我想查看全部任务，并区分完成和未完成。
3. 我想把某条任务标记为已完成。
4. 我想删除不再需要的任务。

它们直接对应四个命令：add、list、done 和 delete。第一版不做截止日期、优先级、标签、账号和云同步，因为这些功能不会帮助我们更好地理解最小闭环。

约定命令与输出

先设计交互，再实现内部代码：

todo add 学习 Go
已添加 #1 学习 Go

todo list
[ ] #1 学习 Go

todo done 1
已完成 #1 学习 Go

编号必须稳定。删除 #1 后，现存的 #2 不应该突然变成 #1，否则用户保存的引用会失效。因此新任务编号取“历史现存最大编号加一”，而不是数组长度加一。

明确错误边界

至少处理以下错误：

• 没有输入命令时，告诉用户有哪些命令。
• add 后没有内容时，拒绝创建空任务。
• done 或 delete 的编号不是正整数时，返回明确错误。
• 编号格式正确但任务不存在时，指出具体编号。
• JSON 文件损坏时停止操作，不用空列表覆盖旧文件。

最后一条尤其重要。软件不能为了“看起来没报错”而吞掉数据问题。

本章验收

在写代码前，你应该能用一句话解释项目边界：

这是一个单用户、本地运行、使用 JSON 保存数据的待办清单 CLI，第一版只完成任务生命周期。

如果又想到提醒、同步或界面功能，先记入后续清单，不要改变当前验收标准。下一章开始搭建最小代码骨架。