很多程序员让 AI 写命令行工具时第一句话就是“帮我写一个脚本。”结果经常是能跑但参数混乱、错误提示随意、边界场景没人管过几天自己也不敢复用。这一讲给你一套更稳定的做法先让 AI 设计 CLI 的使用方式再让它写代码。建议收藏这篇后面遇到日志清洗、批量重命名、接口压测、数据导入、日报生成这类重复工作都可以直接套这套模板。我会继续更新 AI 编程提效实战关注后可以按系列追更。先判断这个需求适不适合做成 CLI不是所有重复动作都值得做命令行工具。适合 CLI 的任务通常有 4 个特征输入稳定比如文件路径、环境名、日期范围、接口地址输出稳定比如生成文件、打印报告、返回 JSON、退出码重复频率高每周、每天、每次发布都要做可被自动化串起来能放进 shell、CI、定时任务或脚本链路如果一个任务还在探索期手工操作和临时脚本可能更合适。如果它已经重复出现 3 次就可以考虑让 AI 帮你设计 CLI。不要先写代码先让 AI 设计命令低效问法是帮我写一个命令行工具读取 CSV然后生成统计结果。这个问法的问题是AI 会直接开始写实现但你还没告诉它命令叫什么参数怎么命名哪些参数必填错误时怎么提示输出给人看还是给程序消费失败时退出码如何约定更好的第一步是让 AI 先输出“命令设计草案”我想做一个命令行工具用于读取 CSV 文件并生成字段统计报告。 请先不要写代码先帮我设计 CLI 使用方式要求包含 1. 命令名称 2. 子命令设计 3. 必填参数和可选参数 4. 示例命令 5. 输出格式 6. 错误提示和退出码 7. 后续适合自动化接入的地方 请给出 2 到 3 套方案并说明你推荐哪套。这一步能把 AI 从“写脚本模式”切到“产品化工具设计模式”。一个可复用的 CLI 设计清单让 AI 设计 CLI 时我通常会检查 7 项命令名是否短、稳定、能表达用途子命令是否围绕动作拆分而不是围绕代码模块拆分参数名是否符合常见习惯比如--input、--output、--format默认值是否保守不默认删除、不默认覆盖、不默认写生产环境输出是否区分人读模式和机器读模式错误提示是否告诉用户“哪里错、怎么改”是否有--dry-run、--verbose、--help这类工程化选项比如一个日志归档工具可以设计成logpack scan --dir ./logs --since 7d logpack archive --dir ./logs --output ./dist --dry-run logpack archive --dir ./logs --output ./dist --format json这比“运行 script.py然后传几个位置参数”更容易维护。让 AI 同时给“坏设计”和“好设计”我建议每次都让 AI 做一次对比。命令行工具最容易踩的坑不在算法而在交互设计。坏设计通常长这样python tool.py a.csv b.json 1 true你过两周再看根本不知道1和true分别是什么意思。更好的设计应该是csvstat run --input a.csv --output b.json --min-count 1 --include-empty它长一点但更可读、更适合团队协作也更适合写进文档和 CI。写代码前让 AI 补齐验收样例CLI 工具最怕“看起来能跑”。所以在进入实现前要让 AI 先给验收样例。至少包含正常输入输出应是什么缺少必填参数错误提示是什么输入文件不存在如何退出输出文件已存在默认覆盖还是拒绝--format json输出是否能被脚本解析--dry-run是否只展示计划不产生副作用可以这样问基于上面的 CLI 设计请先生成验收用例不要写实现。 每个用例包含 - 场景 - 示例命令 - 预期 stdout - 预期 stderr - 预期退出码 - 是否产生文件副作用 请覆盖正常路径、参数缺失、文件不存在、输出覆盖、dry-run、JSON 输出。有了验收样例再让 AI 写代码就不容易变成“生成一堆能跑但没人敢用的脚本”。最后再让 AI 实现到这里AI 已经拿到了 4 类上下文任务背景CLI 交互设计参数和输出约定验收用例这时再写代码质量会明显稳定。你可以继续补一句现在请基于上述 CLI 设计和验收用例实现第一版。 要求 1. 使用 Python argparse 2. 代码结构简单不引入不必要依赖 3. 对所有错误返回明确退出码 4. 提供 --help、--dry-run、--verbose 5. 在回答末尾说明如何本地验证这些验收用例如果是 Node.js、Go、Rust 也一样把语言和依赖限制写清楚即可。总结让 AI 帮你设计命令行工具不要从“写代码”开始而要按这个顺序走判断任务是否适合 CLI先设计命令名、子命令和参数明确输出格式、错误提示和退出码对比坏设计和好设计先生成验收用例再实现代码这套流程的核心不是把脚本写复杂而是让重复工作变成可复用、可维护、可交给别人使用的工具。下一讲我会继续写“AI 写前端页面时最常见的 7 个问题”。如果你正在把 AI 用到真实开发流程里可以关注这个系列后面会持续更新可复制的 AI 编程工作流。
第 24 讲:如何让 AI 帮你设计命令行工具
发布时间:2026/7/9 1:48:32
很多程序员让 AI 写命令行工具时第一句话就是“帮我写一个脚本。”结果经常是能跑但参数混乱、错误提示随意、边界场景没人管过几天自己也不敢复用。这一讲给你一套更稳定的做法先让 AI 设计 CLI 的使用方式再让它写代码。建议收藏这篇后面遇到日志清洗、批量重命名、接口压测、数据导入、日报生成这类重复工作都可以直接套这套模板。我会继续更新 AI 编程提效实战关注后可以按系列追更。先判断这个需求适不适合做成 CLI不是所有重复动作都值得做命令行工具。适合 CLI 的任务通常有 4 个特征输入稳定比如文件路径、环境名、日期范围、接口地址输出稳定比如生成文件、打印报告、返回 JSON、退出码重复频率高每周、每天、每次发布都要做可被自动化串起来能放进 shell、CI、定时任务或脚本链路如果一个任务还在探索期手工操作和临时脚本可能更合适。如果它已经重复出现 3 次就可以考虑让 AI 帮你设计 CLI。不要先写代码先让 AI 设计命令低效问法是帮我写一个命令行工具读取 CSV然后生成统计结果。这个问法的问题是AI 会直接开始写实现但你还没告诉它命令叫什么参数怎么命名哪些参数必填错误时怎么提示输出给人看还是给程序消费失败时退出码如何约定更好的第一步是让 AI 先输出“命令设计草案”我想做一个命令行工具用于读取 CSV 文件并生成字段统计报告。 请先不要写代码先帮我设计 CLI 使用方式要求包含 1. 命令名称 2. 子命令设计 3. 必填参数和可选参数 4. 示例命令 5. 输出格式 6. 错误提示和退出码 7. 后续适合自动化接入的地方 请给出 2 到 3 套方案并说明你推荐哪套。这一步能把 AI 从“写脚本模式”切到“产品化工具设计模式”。一个可复用的 CLI 设计清单让 AI 设计 CLI 时我通常会检查 7 项命令名是否短、稳定、能表达用途子命令是否围绕动作拆分而不是围绕代码模块拆分参数名是否符合常见习惯比如--input、--output、--format默认值是否保守不默认删除、不默认覆盖、不默认写生产环境输出是否区分人读模式和机器读模式错误提示是否告诉用户“哪里错、怎么改”是否有--dry-run、--verbose、--help这类工程化选项比如一个日志归档工具可以设计成logpack scan --dir ./logs --since 7d logpack archive --dir ./logs --output ./dist --dry-run logpack archive --dir ./logs --output ./dist --format json这比“运行 script.py然后传几个位置参数”更容易维护。让 AI 同时给“坏设计”和“好设计”我建议每次都让 AI 做一次对比。命令行工具最容易踩的坑不在算法而在交互设计。坏设计通常长这样python tool.py a.csv b.json 1 true你过两周再看根本不知道1和true分别是什么意思。更好的设计应该是csvstat run --input a.csv --output b.json --min-count 1 --include-empty它长一点但更可读、更适合团队协作也更适合写进文档和 CI。写代码前让 AI 补齐验收样例CLI 工具最怕“看起来能跑”。所以在进入实现前要让 AI 先给验收样例。至少包含正常输入输出应是什么缺少必填参数错误提示是什么输入文件不存在如何退出输出文件已存在默认覆盖还是拒绝--format json输出是否能被脚本解析--dry-run是否只展示计划不产生副作用可以这样问基于上面的 CLI 设计请先生成验收用例不要写实现。 每个用例包含 - 场景 - 示例命令 - 预期 stdout - 预期 stderr - 预期退出码 - 是否产生文件副作用 请覆盖正常路径、参数缺失、文件不存在、输出覆盖、dry-run、JSON 输出。有了验收样例再让 AI 写代码就不容易变成“生成一堆能跑但没人敢用的脚本”。最后再让 AI 实现到这里AI 已经拿到了 4 类上下文任务背景CLI 交互设计参数和输出约定验收用例这时再写代码质量会明显稳定。你可以继续补一句现在请基于上述 CLI 设计和验收用例实现第一版。 要求 1. 使用 Python argparse 2. 代码结构简单不引入不必要依赖 3. 对所有错误返回明确退出码 4. 提供 --help、--dry-run、--verbose 5. 在回答末尾说明如何本地验证这些验收用例如果是 Node.js、Go、Rust 也一样把语言和依赖限制写清楚即可。总结让 AI 帮你设计命令行工具不要从“写代码”开始而要按这个顺序走判断任务是否适合 CLI先设计命令名、子命令和参数明确输出格式、错误提示和退出码对比坏设计和好设计先生成验收用例再实现代码这套流程的核心不是把脚本写复杂而是让重复工作变成可复用、可维护、可交给别人使用的工具。下一讲我会继续写“AI 写前端页面时最常见的 7 个问题”。如果你正在把 AI 用到真实开发流程里可以关注这个系列后面会持续更新可复制的 AI 编程工作流。