完成第一个小任务

第一次练习，选一个即使改错也容易看出来的任务。这里用本站工具卡片的说明文案：把“个人信息生成”的用途写清楚，不改工具功能。

这是基于现有文件的教学练习。如果当前文案已经准确，检查后可以得出“无需修改”，不要为了演示制造一次 diff。

先看清工作区

在项目根目录运行：

git status --short
git diff -- src/lib/utility-tools.ts

这两条命令只读。第一条告诉你哪些文件已有变化；第二条帮助区分目标文件中的旧改动与接下来的练习。

工作区不必强制干净。但如果同一段代码正在被别人修改，先避开这段或协调；不要让 Agent 为了“准备环境”清空、暂存或提交已有改动。

交出一条能检查的任务

请检查 src/lib/utility-tools.ts 中“个人信息生成”的说明。
文案需要表达：仅用于开发测试，数据在浏览器本地生成，
不代表真实身份，不可用于注册或身份验证。
 
先读取该工具的数据与实际实现，确认这些表述属实。
若已有文案满足要求，说明无需修改；否则只调整 description。
保留名称、链接、分类、数据策略与其他工具不变。
不要安装依赖、提交或发布。
 
完成后展示实际 diff，运行项目已有检查，
并到 /tools 确认这张卡片文字完整可读。

这里没有规定“必须改几行”。判断标准是事实正确、范围正确、页面可读。限制 description 是本次练习的边界；如果实现根本不是本地生成，就应报告冲突，不能把虚假隐私承诺写进卡片。

观察三个节点

开始前，它应先确认文件和目标条目真实存在。本站的数据字段是 destination、categories 等；如果它凭印象虚构一个 tools.json，就还没读到实际入口。

修改时，看 diff 是否只影响目标说明。顺手重命名全部工具、重排分类、替换组件，都不属于这次任务。

交付时，把它的结论和证据对上：

场景	可观察的预期	检查方式
说明与实现一致	不承诺实现未提供的能力	阅读工具交互逻辑
确需调整说明	仅目标条目的 description 变化	Git diff
文案已经符合要求	不产生无意义改动	原文与需求逐项比较
桌面与窄屏访问工具页	文字可读，卡片链接仍正确	浏览器打开 /tools

本站有 npm run lint、npm run test、npm run build，统一入口是 npm run verify。其他项目先看它自己的 package.json，不要臆造 typecheck 命令。

不合格的交付怎样追问

如果收到“已优化文案，体验更好”，可以只追问缺失证据：

请贴出改前与改后的 description，说明每句事实的代码依据。
列出实际执行的检查及结果。
如果没有检查浏览器，就写“未检查”，不要用构建通过代替。

如果它说构建失败，先看失败原因。依赖下载被网络拦住、MDX 编译错误、与本次无关的旧测试失败，需要不同处理。一次修改尚未完成验证，不等于代码必然错误，但也不能报成全部通过。

什么时候结束

你能回答下面三问，这次练习才算有收获：

我能指出改了什么，或者为什么不需要改吗？
我能验证文案的事实，而不是只觉得语句流畅吗？
我能区分已经检查的结果和仍然未知的部分吗？

把最终 diff 留给自己审阅。是否提交、推送或发布，是之后的独立决定。