发现
从日常反复出现的下载、改名、归位动作里，记录一个足够具体的问题。
例如：同一事项的附件分散在邮件、下载目录和聊天截图里。DEVELOPMENT JOURNAL / PERSONAL EXPERIMENT
把一个小麻烦，
拆成一条能检查的流程
这组手记记录我围绕本地资料整理所做的个人开发尝试：问题从哪里来、规则如何写下、哪些步骤可以辅助、哪些地方必须停下来由人确认。
WHERE IT STARTED
我并不是从“做工具”开始的
起点往往只是一个重复动作：附件下载后要改名、截图要排序、表格里同一个编号反复复制。它们都不难，但一旦数量增加，就容易把注意力耗在机械操作和事后补救上。
我后来意识到，真正需要被整理的不是文件本身，而是文件和一件事之间的关系。它属于什么、现在处于什么状态、需要谁确认、最终放在哪里——这些问题清楚后，工具才有可以执行的边界。
因此，这里的记录不把小工具写成万能答案。它只讨论如何让重复步骤少一些、让异常更早被看见，并保留人可以停止、检查和改正的位置。
HOW I BREAK DOWN A FLOW
一次实践，通常经过四步
这四步不是开发流程模板，而是我用来避免“还没弄清问题就开始写功能”的自我检查。每一步都有可以停下来的理由。
拆分
把流程拆成输入、识别、候选结果、人工确认和归档五个阶段。
每个阶段都要能说清输入是什么、可能出什么例外。试跑
只用少量、脱敏或可回退的资料验证规则，不直接处理整批文件。
先检查文件名、顺序、路径和重复项，再扩大范围。复盘
记录没处理对的情况，决定是补规则、改输入，还是保留人工步骤。
不是每个问题都适合自动化，明确停止点同样重要。DESIGN PRINCIPLES
四个持续修正的判断
这些原则来自文件整理、表格处理和初步规则试验。它们并不追求一次解决所有情况，而是帮助我在出现例外时，知道该往哪里回退。
先看输入，再谈输出
邮件附件、截图和表格的来源各不相同。先把输入格式、命名和缺失信息看清楚，才知道一条规则能不能稳定执行。
候选结果不等于最终结果
工具可以给出初步分类、候选文件名和待处理清单；但归属、版本、异常与最终确认仍要回到人手里。
让资料留在可控的位置
我更看重本地保存、可查看、可备份和可还原。资料的去向讲不清楚时，再多的功能也不应该贸然加入。
把失败当成下一条规则
命名冲突、字段缺失和识别错误并不只是问题，它们会告诉我：原来的规则少了哪一个条件。
THE HUMAN CHECKPOINT
工具做准备，
确认仍然由人完成
自动化最容易被误解成“省去所有判断”。我的实践恰好相反：工具越能处理重复步骤，人越应该把注意力放回边界、异常和最终确认。
可以辅助
读取固定位置的文件、整理候选清单、按已写明的规则生成名称、检查空值与重复项。
必须确认
资料是否属于某一事项、哪个版本可继续使用、异常信息是否需要补充或联系相关人员。
不会替代
业务判断、对外沟通、凭证真实性确认，以及任何需要由实际责任人作出的决定。
A NOTE TO MYSELF
每一次出错，
都值得留下一个原因。
一次文件名冲突、一次没有识别对的字段、一次资料归属不明，往往比顺利完成更有价值。它们会提醒我：是规则不够、输入不够清楚，还是这一步原本就不该自动处理。
这里仅分享个人的开发过程和方法反思，不提供软件下载、账号服务、交易、报价或定制承接。