企业官网建设流程全解析

很多程序员让 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 项：

1. 命令名是否短、稳定、能表达用途

2. 子命令是否围绕动作拆分，而不是围绕代码模块拆分

3. 参数名是否符合常见习惯，比如--input、--output、--format

4. 默认值是否保守，不默认删除、不默认覆盖、不默认写生产环境

5. 输出是否区分人读模式和机器读模式

6. 错误提示是否告诉用户“哪里错、怎么改”

7. 是否有--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 帮你设计命令行工具，不要从“写代码”开始，而要按这个顺序走：

1. 判断任务是否适合 CLI

2. 先设计命令名、子命令和参数

3. 明确输出格式、错误提示和退出码

4. 对比坏设计和好设计

5. 先生成验收用例，再实现代码

这套流程的核心不是把脚本写复杂，而是让重复工作变成可复用、可维护、可交给别人使用的工具。

下一讲我会继续写“AI 写前端页面时最常见的 7 个问题”。如果你正在把 AI 用到真实开发流程里，可以关注这个系列，后面会持续更新可复制的 AI 编程工作流。