文章总结： 本文实测阶跃星辰Step5Preview模型在真实Linux环境下的Coding能力，以开发SSH安全日志分析工具为任务，覆盖需求理解、方案设计、代码生成、实机调试到最终交付全流程。测试关注首版可运行性、需求完整性、错误修复能力及交付质量，并记录API调用成本。结果显示该模型具备完成完整工程任务的能力，建议在实际应用中注重多轮上下文维护与异常处理。
综合评分： 83
文章分类： AI安全,安全工具,安全开发,实战经验
Step 5 Preview Coding 实测：从 API 接入到 Linux 实机 Debug，它能把工程任务做完吗？
原创
z释然z
z释然z
释然IT杂谈
2026年9月20日 18:29
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
最近拿到了阶跃星辰Step 5 Preview的内测资格。
这次我没有先去跑各种榜单，也没有用“写个排序算法”“解释一下 Linux Load”这种题目来判断它的 Coding 能力。
除了能力，这次我也顺手关注了一下它在多轮 Coding 任务里的成本表现，后面一起看。
我更想测一个实际问题：
给 Step 5 Preview 一个完整的 IT 工程任务，从需求理解、方案设计、代码生成，到 Linux 实机运行、报错修复和最终验收，它能不能真正把事情做完？
所以这次测试全部放在真实 Linux 环境里完成。
测试链路如下：
相比单纯看模型“会不会写代码”，我更关注：
第一版能不能跑、需求有没有漏、遇到错误会不会修、修完会不会引入新问题，最终到底能不能交付。
一、先确定这次到底测什么
本次测试对象是：
Step-5-Preview
测试任务也尽量贴近日常运维和安全工作：
从零开发一个 Linux SSH 安全日志分析工具。
最终目标：
这个项目不算复杂，但涉及的东西不少：
也就是说，这次测试的并不只是 Python。
还包括：
-
Linux 实战能力
-
需求理解
-
CLI 设计
-
API 调用
-
安全意识
-
异常处理
-
Debug
-
工程交付
这也是我选择这个任务的原因。
二、测试环境先准备好
为了让整个测试过程能够留档，我单独建了一个目录。
mkdir -p ~/step-5-preview
cd ~/step-5-preview
最终整个目录会逐渐变成：
这样后面每一次请求、每一轮返回、每一次修改和最终报告都能留下原始记录。
三、第一步：先把 Step 5 Preview API 跑通
先配置 API Key。
这次统一使用：
STEP_API_KEY
设置：
export STEP_API_KEY="你的真实API_KEY"
确认环境变量已经存在：
echo "${STEP_API_KEY:+STEP_API_KEY 已设置}"
正常应该看到：
STEP_API_KEY 已设置
这里不建议直接：
echo $STEP_API_KEY
避免完整 Key 出现在终端截图或者测试记录中。
先做一次最简单的 API 调用
curl https://api.stepfun.com/v1/chat/completions \
-H "Authorization: Bearer ${STEP_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"model": "step-5-preview",
"messages": [
{
"role": "user",
"content": "你好，请介绍一下你自己"
}
]
}'
这一轮我不评价模型能力。
只确认：
是不是正常。
只有基础链路稳定，后面的 Coding 测试才有意义。
四、长 Prompt 不再直接塞 curl
到了正式 Coding 测试，需求已经不是一句话了。
如果直接把几百行 Prompt 塞进：
curl -d '{ ... }'
很容易因为：
换行
双引号
反斜杠
特殊字符
终端粘贴
破坏 JSON。
我实际测试时就遇到了：
invalid request format
所以正式测试改成：
这套方式稳定很多。
五、把完整需求保存成 prompt.txt
执行：
vi prompt.txt
这次我不会简单告诉 Step 5 Preview：
“帮我写个 SSH 日志分析工具。”
而是直接给完整工程需求。
核心内容如下：
你现在是一名 Linux 系统运维工程师、安全工程师和 Python 开发工程师。
我正在一台真实 Linux 测试机上测试你的 Coding 能力。
你的任务是从零开发一个：
Linux SSH 安全日志分析工具
项目文件名：
ssh_analyzer.py
====================
一、测试协作方式
====================
你无法直接操作我的 Linux 终端。
你负责：
分析需求；
设计程序；
编写代码；
给出需要执行的 Linux 命令；
根据我返回的真实执行结果分析问题；
如果程序报错，根据错误继续修改；
持续迭代直到关键测试通过。
我负责：
在真实 Linux 环境执行你给出的命令；
将终端输出和报错原样返回给你；
按修改后的代码重新测试。
不要假设命令已经执行成功。
没有看到我的真实终端输出前，
不要宣布项目已经完成。
====================
二、项目目标
====================
实现以下流程：
Linux SSH 日志
→ 本地脚本预处理
→ 筛选关键 SSH / sudo 安全事件
→ 调用 step-5-preview API
→ 生成 Markdown 安全分析报告
→ 运维人员人工复核
====================
三、运行环境
====================
Linux
Python 3.8+
优先使用 Python 标准库。
如果必须使用第三方库，
请说明原因并给出安装命令。
====================
四、Step 5 Preview API
====================
模型：
step-5-preview
API：
https://api.stepfun.com/v1/chat/completions
API Key 必须从环境变量读取：
STEP_API_KEY
禁止：
将 API Key 硬编码进源码；
将完整 API Key 写入日志；
在错误信息中泄露完整 API Key。
====================
五、日志输入
====================
支持两种模式：
--file
读取指定日志文件，例如：
python3 ssh_analyzer.py \
--file /var/log/auth.log
--last
读取最近 N 分钟 SSH 日志，例如：
python3 ssh_analyzer.py \
--last 30
通过 journalctl 获取。
--file 和 --last 必须互斥。
====================
六、日志预处理
====================
不要把完整 auth.log 直接提交给模型。
先在本地筛选：
Failed password
Accepted password
Accepted publickey
Invalid user
sudo
尽量保留：
时间
主机名
用户名
来源 IP
认证结果
sudo 命令
如果没有相关事件：
输出：
未发现需要分析的 SSH / sudo 安全事件
然后退出。
不要调用 stpe-5-preview。
====================
七、安全分析
====================
分析结果固定输出：
【事件时间线】
【已确认事实】
【待验证风险】
【风险等级】
【排查建议】
【推荐 Linux 命令】
必须遵守：
Failed password 不等于已经入侵；
Accepted password 不等于攻击者登录；
sudo 不等于恶意提权；
crontab -e 不等于已经植入后门；
必须区分事实、推测、待验证项；
证据不足必须明确说明。
====================
八、命令行参数
====================
支持：
--file
--last
--output
必须支持：
python3 ssh_analyzer.py --help
====================
九、Markdown 报告
====================
报告至少包含：
# SSH 安全日志分析报告
## 基本信息
## 事件时间线
## 已确认事实
## 待验证风险
## 风险等级
## 排查建议
## 推荐命令
====================
十、异常处理
====================
必须处理：
日志文件不存在；
STEP_API_KEY 未设置；
--last 不是整数；
空日志；
没有相关安全事件；
journalctl 执行失败；
API 超时；
HTTP 401；
HTTP 403；
HTTP 429；
HTTP 5xx；
API 返回异常 JSON；
--file 和 --last 同时出现。
不能直接把 Python Traceback
作为最终处理结果。
====================
十一、安全边界
====================
程序只负责：
读取日志；
筛选日志；
分析日志；
生成建议。
禁止自动：
封禁 IP；
删除账号；
修改 SSH；
修改防火墙；
修改 crontab；
重启服务器；
删除文件；
执行模型返回的命令。
所有处置由人工确认。
====================
十二、开发流程
====================
第一步：
先分析需求。
给出：
程序结构；
模块划分；
日志获取方式；
参数设计；
API 调用方式；
异常处理方案。
现在不要写代码。
等我确认后再进入下一阶段。
后续要求：
生成第一版代码；
进行 Python 语法测试；
测试 --help；
测试真实日志；
检查 Markdown；
测试异常场景；
真实报错后继续修改；
关键测试通过后再宣布完成。
现在只执行第一步：
分析需求并给出开发方案。
不要直接开始写代码。
这里有一个关键点：
第一轮故意不让 Step 5 Preview 写代码。
我要先看它怎么理解需求。
六、先测需求理解，而不是急着看代码
完整需求发出去后，我第一轮主要检查 Step 5 Preview有没有主动拆出：
同时观察它有没有注意到：
如果这些关键约束在方案阶段就漏掉，后面即使一次输出 500 行代码，我也不会认为需求理解表现很好。
七、生成合法 JSON 再调用
先安装 jq：
sudo apt update
sudo apt install -y jq
把 Prompt 转成 messages：
jq -n \
--rawfile prompt prompt.txt \
'[
{
"role": "user",
"content": $prompt
}
]' > messages.json
再生成 API payload：
jq -n \
--slurpfile messages messages.json \
'{
model: "step-5-preview",
messages: $messages[0]
}' > payload.json
先验证：
jq empty payload.json
没有输出，就说明 JSON 格式正常。
八、第一次正式调用，同时记录性能数据
执行：
curl -sS \
-o response_01.json \
-w '\nHTTP_CODE=%{http_code}\nTIME_TOTAL=%{time_total}s\nSIZE=%{size_download} bytes\n' \
https://api.stepfun.com/v1/chat/completions \
-H "Authorization: Bearer ${STEP_API_KEY}" \
-H "Content-Type: application/json" \
--data-binary @payload.json
这一轮我会同时记录：
HTTP_CODE
TIME_TOTAL
SIZE
然后提取回答：
jq -r '.choices[0].message.content' \
response_01.json > response_01.txt
查看：
cat response_01.txt
再查看 Token：
jq '.usage' response_01.json
这样第一轮就有：
完整留档。
九、方案确认后，再让它写第一版代码
如果方案没有明显问题，我继续第二轮：
方案确认。
现在进入第二阶段。
请按照刚才确认的设计，
从零输出完整第一版：
ssh_analyzer.py
保持之前全部需求和安全边界不变。
代码完成后不要假设已经运行成功。
最后只告诉我下一步需要在 Linux
执行哪条验证命令。
这里有个 API 使用细节必须注意：
Chat Completions 不会自动记住上一轮。
第二轮必须同时带上：
第一轮完整用户需求
+
第一轮 step 5 preview 回答
+
第二轮用户指令
否则所谓“方案确认”对模型来说没有上下文。
十、维护多轮上下文
创建第二轮 Prompt：
cat > prompt_02.txt <<'EOF'
方案确认。
现在进入第二阶段。
请按照刚才的设计，从零输出完整第一版：
ssh_analyzer.py
保持之前所有需求和安全边界不变。
代码完成后不要假设已经运行成功。
最后只告诉我下一步需要在 Linux 执行哪条验证命令。
EOF
把上一轮 Step 5 Preview 回答和新指令加入：
jq \
--rawfile assistant response_01.txt \
--rawfile user prompt_02.txt \
'. + [
{
"role": "assistant",
"content": $assistant
},
{
"role": "user",
"content": $user
}
]' messages.json > messages_tmp.json
替换：
mv messages_tmp.json messages.json
重新生成：
jq -n \
--slurpfile messages messages.json \
'{
model: "step-5-preview",
messages: $messages[0]
}' > payload.json
然后进行第二轮调用：
curl -sS \
-o response_02.json \
-w '\nHTTP_CODE=%{http_code}\nTIME_TOTAL=%{time_total}s\n' \
https://api.stepfun.com/v1/chat/completions \
-H "Authorization: Bearer ${STEP_API_KEY}" \
-H "Content-Type: application/json" \
--data-binary @payload.json
提取：
jq -r '.choices[0].message.content' \
response_02.json > response_02.txt
这一轮开始真正进入 Coding。
十一、代码出来以后，不看感觉，直接上 Linux
把 Step 5 Preview 输出的 Python 保存为：
ssh_analyzer.py
在当前目录执行：
awk '
/^```python[[:space:]]*$/ {code=1; next}
code && /^```[[:space:]]*$/ {exit}
code {print}
' response_02.txt > ssh_analyzer.py
然后确认文件确实生成了：
ls -lh ssh_analyzer.py
再检查开头：
head -30 ssh_analyzer.py
以及结尾：
tail -30 ssh_analyzer.py
正常情况下，结尾应该能看到类似你Step 5 Preview输出中的：
if __name__ == "__main__":
try:
main()
except KeyboardInterrupt:
...
第一关先做语法测试：
python3 -m py_compile ssh_analyzer.py
如果无输出：
PASS
如果出现：
SyntaxError
IndentationError
就把完整错误保存下来：
python3 -m py_compile ssh_analyzer.py \
2>&1 | tee error_01.txt
不要人工帮它改。
后面把真实错误继续提交给 Step 5 Preview。
这一项测的是：
第一版代码到底是不是可执行代码，而不是看起来像代码。
十二、第二关：测试命令行参数
语法通过之后：
python3 ssh_analyzer.py --help
确认至少存在：
--file
--last
--output
然后故意测试：
python3 ssh_analyzer.py \
--file ssh_test.log \
--last 30
原始需求明确规定：
--file
和
--last
必须互斥。
如果程序仍然继续执行：
FAIL
这一项测的是：
需求有没有真正落实到代码。
十三、准备一份固定测试日志
为了保证每一轮输入一致，我使用固定测试数据。
cat > ssh_test.log <<'EOF'
Sep 16 01:58:02 web01 sshd[21001]: Accepted publickey for ops from 10.10.10.15 port 44122 ssh2
Sep 16 01:58:08 web01 sudo: ops : USER=root ; COMMAND=/usr/bin/systemctl status nginx
Sep 16 02:13:41 web01 sshd[21843]: Failed password for root from 45.83.10.20 port 52310 ssh2
Sep 16 02:13:45 web01 sshd[21847]: Failed password for root from 45.83.10.20 port 52364 ssh2
Sep 16 02:14:02 web01 sshd[21861]: Failed password for admin from 45.83.10.20 port 52521 ssh2
Sep 16 02:16:37 web01 sshd[21910]: Accepted password for admin from 45.83.10.20 port 53114 ssh2
Sep 16 02:17:04 web01 sudo: admin : USER=root ; COMMAND=/usr/bin/id
Sep 16 02:18:21 web01 sudo: admin : USER=root ; COMMAND=/usr/bin/crontab -e
Sep 16 02:22:04 web01 sshd[22113]: Accepted publickey for backup from 10.10.10.30 port 43921 ssh2
EOF
这份日志故意同时包含：
正常内网公钥登录
正常 sudo
公网登录失败
同一公网 IP 成功登录
sudo
crontab 编辑
正常 backup 登录
目的就是测试模型会不会把所有行为都无脑判成攻击。
十四、正式跑完整链路
执行：
python3 ssh_analyzer.py \
--file ssh_test.log \
--output report.md
预期流程：
检查：
ls -lh report.md
然后：
cat report.md
这一轮不仅是在测试程序。
也是第一次真正测试 Step 5 Preview 的安全分析能力。
十五、安全分析重点看什么
测试数据里最值得关注的是：
Step 5 Preview应该识别出这条行为链值得重点关注。
但同时还存在：
10.10.10.15
Accepted publickey for ops
以及：
10.10.10.30
Accepted publickey for backup
这些行为不能仅仅因为出现 SSH 就全部判定为攻击。
更关键的是：
crontab -e
只能证明：
admin执行了 crontab 编辑操作。
不能直接写成：
“攻击者已经通过计划任务建立持久化后门。”
是否真正修改、写了什么内容，还需要后续取证。
这一项测试的实际上是：
事件关联
误报控制
证据边界
幻觉控制
十六、再测试真实 journalctl
执行：
python3 ssh_analyzer.py \
--last 30 \
--output ssh_last30.md
这里遇到
非常适合继续做 Debug 实测 先不要人工修，直接交给 Step 5 Preview 可以创建：
nano debug_01.txt
写：
这是 Linux 测试机对第一版 ssh_analyzer.py 的真实测试结果。
执行：
python3 ssh_analyzer.py \
--last 30 \
--output ssh_last30.md
真实结果：
[INFO] 正在通过 journalctl 获取最近 30 分钟日志...
[ERROR] 程序执行异常: ValueError: journalctl 执行失败 (返回码 1)。
进一步测试：
journalctl --since "-10 minutes ago" --no-pager
结果：
Failed to parse timestamp: -10 minutes ago
journalctl --since "10 minutes ago" --no-pager
结果：
命令可以正常执行并返回系统日志。
因此目前已经确认：
1. 第一版代码使用的 "-N minutes ago" 在当前 Linux 环境无法被 journalctl 解析；
2. 正确可用格式为 "N minutes ago"；
3. 当前代码没有指定 SSH unit，因此获取了整个 systemd journal，而不是只获取 SSH 日志。
请根据这些真实测试结果进行 Debug。
要求：
1. 先说明根因；
2. 不要推倒重写项目；
3. 只修改 --last / journalctl 相关逻辑；
4. 不要破坏已经通过的 --file 模式；
5. 修正 journalctl 时间参数；
6. 合理兼容 ssh.service / sshd.service；
7. --last 应优先获取 SSH 相关日志；
8. journalctl 失败时保留有价值的 stderr；
9. 保持 Python 3.8+ 兼容；
10. 给出修改后的完整 ssh_analyzer.py；
11. 不要假设修改已经成功；
12. 最后只告诉我下一条应该执行的 Linux 验证命令。
必须等待我返回真实测试结果后才能继续宣布完成。
保存以后：
cat debug_01.txt
确认内容没问题。 把第二轮回答 + Debug 信息追加进 messages.json
jq \
--rawfile assistant response_02.txt \
--rawfile user debug_01.txt \
'. + [
{
"role": "assistant",
"content": $assistant
},
{
"role": "user",
"content": $user
}
]' messages.json > messages_tmp.json
验证 JSON：
jq empty messages_tmp.json
如果没有任何输出，说明正常。 重新生成第三轮 payload.json
jq -n \
--slurpfile messages messages.json \
'{
model: "step-5-preview",
messages: $messages[0]
}' > payload.json
发起第三轮 Debug 调用
curl -sS \
-o response_03.json \
-w '\nHTTP_CODE=%{http_code}\nTIME_TOTAL=%{time_total}s\nSIZE=%{size_download} bytes\n' \
https://api.stepfun.com/v1/chat/completions \
-H "Authorization: Bearer ${STEP_API_KEY}" \
-H "Content-Type: application/json" \
--data-binary @payload.json
后提取第三轮回答：
jq -r '.choices[0].message.content' \
response_03.json > response_03.txt
不要直接覆盖旧代码，先备份
cp ssh_analyzer.py ssh_analyzer_v1.py
从 response_03.txt 提取修复后的代码
awk '
/^```python[[:space:]]*$/ {code=1; next}
code && /^```[[:space:]]*$/ {exit}
code {print}
' response_03.txt > ssh_analyzer.py
重新跑刚才失败的测试
python3 ssh_analyzer.py \
--last 30 \
--output ssh_last30.md
仍然失败，继续不要自己改。创建：
debug_02.txt
直接写：
这是第二版 ssh_analyzer.py 的真实 Linux 复测结果。
执行：
python3 ssh_analyzer.py \
--last 30 \
--output ssh_last30.md
真实结果：
[ERROR] journalctl 执行失败 (退出码 1): Failed to parse timestamp: -30 minutes ago
请确认系统使用 systemd 且当前用户有权限读取日志。
此前已经向你提供过以下真实测试结果：
journalctl --since "-10 minutes ago" --no-pager
结果：
Failed to parse timestamp: -10 minutes ago
而：
journalctl --since "10 minutes ago" --no-pager
可以正常执行。
因此第二版仍然没有修复核心问题。
请检查你当前生成的 ssh_analyzer.py。
重点要求：
1. 先明确说明为什么第二版仍然保留了：
"-N minutes ago"
2. 必须把 journalctl 时间参数修正为：
"N minutes ago"
3. 不要再保留前导负号；
4. 不要只修改错误提示，必须修改实际执行命令；
5. 继续保持 Python 3.8+ 兼容；
6. 不要破坏已经正常工作的 --file 模式；
7. --last 应优先读取 SSH 相关日志；
8. 如果需要兼容 ssh.service / sshd.service，请合理处理；
9. journalctl 执行失败时继续保留 stderr；
10. 给出完整修正版代码；
11. 不要假设已经修复成功；
12. 最后只给出下一条 Linux 验证命令。
请基于真实错误做最小必要修改。
那么执行：
jq \
--rawfile assistant response_03.txt \
--rawfile user debug_02.txt \
'. + [
{
"role": "assistant",
"content": $assistant
},
{
"role": "user",
"content": $user
}
]' messages.json > messages_tmp.json
重新生成：
jq -n \
--slurpfile messages messages.json \
'{
model: "step-5-preview",
messages: $messages[0]
}' > payload.json
再调用下一轮：
curl -sS \
-o response_04.json \
-w '\nHTTP_CODE=%{http_code}\nTIME_TOTAL=%{time_total}s\nSIZE=%{size_download} bytes\n' \
https://api.stepfun.com/v1/chat/completions \
-H "Authorization: Bearer ${STEP_API_KEY}" \
-H "Content-Type: application/json" \
--data-binary @payload.json
提取：
jq -r '.choices[0].message.content' \
response_04.json > response_04.txt
然后从里面提取第三版代码：
awk '
/^```python[[:space:]]*$/ {code=1; next}
code && /^```[[:space:]]*$/ {exit}
code {print}
' response_04.txt > ssh_analyzer_v3.py
复测：
python3 ssh_analyzer_v3.py \
--last 30 \
--output ssh_last30.md
还是有问题继续让他修复 写：
这是第二次 Debug 后的真实 Linux 测试结果。
执行：
python3 ssh_analyzer_v2.py \
--last 30 \
--output ssh_last30.md
程序输出：
[INFO] 获取最近 30 分钟日志
[INFO] 执行命令: journalctl --since -30 minutes ago --no-pager -o short-iso
[ERROR] journalctl 执行失败（退出码 1）: Failed to parse timestamp: -30 minutes ago
[ERROR] 提示：请确认当前用户有权限读取系统日志，可尝试使用 root 运行
但这里不是权限问题。
此前已经确认：
journalctl --since "-30 minutes ago" --no-pager
返回：
Failed to parse timestamp: -30 minutes ago
而：
journalctl --since "30 minutes ago" --no-pager
可以正常返回日志。
即使切换 root，"-30 minutes ago" 仍然属于无法解析的时间格式。
因此当前第二版仍然存在两个问题：
1. 核心 Bug 没有修复
当前实际执行的仍然是：
journalctl --since "-30 minutes ago"
必须修改成：
journalctl --since "30 minutes ago"
2. 错误归因不正确
stderr 已经明确是：
Failed to parse timestamp
这属于参数/时间格式错误，不应该提示为权限问题。
只有 stderr 出现 Permission denied、权限不足等明确证据时，
才应该提示检查 journal 权限。
请基于以上真实证据继续 Debug。
要求：
1. 先解释为什么上一次修复没有修改到真正的时间参数；
2. 必须修改实际 journalctl 命令，而不仅仅修改错误提示；
3. 删除时间字符串前面的负号；
4. 对 stderr 做合理分类；
5. 时间解析失败时提示时间参数错误；
6. 权限错误时才提示权限问题；
7. 不要破坏 --file 模式；
8. 保持 Python 3.8+；
9. --last 应继续优先获取 SSH 相关日志；
10. 不要推倒重写项目，只做最小必要修改；
11. 给出完整修正版 ssh_analyzer.py；
12. 不要宣布修复成功，等待真实 Linux 复测；
13. 最后只给出下一条验证命令。
复测：
python3 ssh_analyzer_v4.py \
--last 30 \
--output ssh_last30.md
这里特别适合测试 Linux 实战能力。
不要自己修。
直接把错误交回 Step 5 Preview。
看它能不能根据实际系统环境调整，而不是继续坚持原来的实现。
十七、正常能跑还不够，开始故意找问题
真正区分 Demo 和工程代码的，是异常场景。
文件不存在
python3 ssh_analyzer.py \
--file notfound.log
预期：
明确提示文件不存在
而不是直接给用户一大段 Traceback。
API Key 缺失
unset STEP_API_KEY
再执行：
python3 ssh_analyzer.py \
--file ssh_test.log
应该在请求 API 之前明确提示 Key 缺失。
测试完成再恢复：
export STEP_API_KEY="你的API_KEY"
非法参数
python3 ssh_analyzer.py --last abc
应该由参数层阻止。
没有安全事件
echo "hello world" > empty.log
然后：
python3 ssh_analyzer.py \
--file empty.log
合理行为：
未发现需要分析的 SSH / sudo 安全事件
并且最关键的一点：
不应该调用 Step 5 Preview API。
参数冲突
python3 ssh_analyzer.py \
--file ssh_test.log \
--last 30
应该直接提示：
--file 与 --last 不能同时使用
这些异常测试很简单，但最容易暴露 AI 代码到底有没有工程意识。
十八、真正关键的测试：报错之后 Step 5 Preview 会怎么处理
我并不要求第一版代码完全正确。
相反，我认为：
第一版出错之后，Step 5 Preview 怎么修，比第一版有没有 Bug 更有价值。
假设终端出现：
Traceback ...
FileNotFoundError ...
我会把完整错误保存下来。
然后创建：
cat > debug_01.txt <<'EOF'
这是 Linux 测试机的真实运行结果：
（粘贴完整报错）
请根据真实错误进行 Debug。
要求：
1. 先说明错误根因；
2. 不要推倒重写项目；
3. 只做最小必要修改；
4. 不要修改已经通过测试的功能；
5. 给出修改后的完整代码；
6. 告诉我应该重新执行哪条命令验证。
EOF
再继续作为下一轮对话提交。
每一轮保留：
response_01
response_02
response_03
response_04
...
最后就能得到一个非常实际的数据：
Step 5 Preview 从第一版到最终通过验收，一共用了多少轮 Debug？
十九、修 Bug 时，还要看有没有回归
例如 Step 5 Preview 为了修：
--last
结果把：
--file
搞坏了。
这就是典型的回归问题。
所以每次修完不能只重测失败项。
还应该至少做一次基本回归：
python3 -m py_compile ssh_analyzer.py
python3 ssh_analyzer.py --help
python3 ssh_analyzer.py \
--file ssh_test.log \
--output report.md
如果修改一个 Bug，又带出两个新 Bug，这也是 Coding 能力评价的重要部分。
二十、测试记录不能靠印象
Step 5 Preview Coding 实测记录
| 测试项 | 结果 | 修改轮次 | 备注 |
| — | — | — | — |
| API 基础调用 | PASS | 0 | Step 5 Preview调用正常 |
| 需求分析 | PASS | 0 | 能完成方案拆分，并识别参数、API、异常处理、安全边界等模块 |
| Python 语法 | PASS | 0 | 脚本已能够进入实际运行阶段 |
| –help | 待测试 | – | 尚未记录实测结果 |
| –file | 待测试 | – | 尚未完成完整实测记录 |
| –last | FAIL | 2+ | journalctl 时间参数错误，仍使用 -30 minutes ago |
| 参数互斥 | 待测试 | – | –file / –last 冲突场景尚待验证 |
| Markdown 报告 | 待测试 | – | –last 尚未跑通，需后续验证 report.md |
| 文件不存在 | 待测试 | – | 尚未执行 notfound.log 测试 |
| Key 缺失 | 待测试 | – | 尚未执行 unset STEP_API_KEY 测试 |
| 空日志 | 待测试 | – | 尚未验证是否做到空日志不调用 API |
| journalctl 异常 | PARTIAL | 2+ | 能捕获退出码和 stderr，但首次错误归因不准确 |
| API Timeout | 待测试 | – | 尚未模拟超时 |
| HTTP 异常 | 待测试 | – | 401 / 403 / 429 / 5xx 尚未实测 |
| 安全研判 | 待测试 | – | 待主流程跑通后检查事件关联、误报和证据边界 |
| 回归测试 | 待测试 | – | Debug 尚未收敛 |
| 最终验收 | IN PROGRESS | – | 当前卡在 --last / journalctl Debug 阶段 |
整个测试结束后，不再用：
“感觉 Step 5 Preview 还不错。”
这种描述。
而是直接看测试结果。
二十一、最终什么情况下才算“完成”
不是模型自己说：
“项目开发完成。”
就算完成。
我会按照实际测试结果验收：
只有关键项目真实通过，我才会认为：
任务完成。
二十二、这次测试真正测的并不是“Python”
表面上看，这次只是写了一个：
SSH 日志分析工具。
实际上它同时测试了：
| 能力 | 实际表现 |
| — | — |
| API | 能不能稳定调用 |
| 需求理解 | 能不能吃完整需求 |
| 方案设计 | 能不能合理拆模块 |
| Python | 能不能生成可执行代码 |
| Linux | journalctl/auth.log 是否准确 |
| CLI | 参数设计是否正确 |
| HTTP | API 异常是否处理 |
| 安全 | 有没有基本安全边界 |
| 日志分析 | 能不能关联关键事件 |
| 幻觉控制 | 能不能区分事实与推测 |
| Debug | 真实错误后会不会修 |
| 回归 | 修改后会不会破坏旧功能 |
| 工程交付 | 最终能不能真正跑起来 |
所以这次并不是在测试：
Step 5 Preview 会不会写代码。
而是在测试：
Step 5 Preview 能不能从需求开始，把一个小型工程任务持续推进到最终验收。
#
写在最后
这次测试下来，我越来越觉得，判断一个 Coding 模型值不值得用，不能只看它能不能一次性生成一大段代码。
真正进入实际工程场景以后，流程往往是：
所以我更关注的，不是 Step 5 Preview第一版代码有多漂亮，而是它在真实 Linux 环境里遇到问题后，能不能继续根据终端反馈定位、修改和收敛，最后把任务真正推进到可用状态。
从这个角度看，会写代码只是起点，能不能完成工程闭环才更重要。
另外，成本也是 Step 5 Preview这次比较值得关注的一点：按照本次给出的单任务成本口径，单任务成本约为 GLM-5.3、Kimi K3 的 35%，约为 Claude Opus 5 的 12.5%。
对于 Coding Agent 这类需要多轮生成、调试、修复和回归验证的场景，这一点会更加明显。因为真正的工程任务往往不是调用一次模型就结束，而是要持续迭代多轮，单任务成本差异最终会被整个执行链路进一步放大。
当然，实际使用成本仍然会受到 Prompt 长度、输出 Token、缓存命中率、任务复杂度以及 Debug 轮次等因素影响。
所以我最终更愿意从两个维度来看 Step-5-preview：
一是，它能不能把事情做完。
二是，把事情做完需要付出多大的成本。
如果后续 Step 5 Preview能在复杂 Debug、跨文件修改、长任务连续执行这些场景里继续保持稳定，那它的价值就不只是“会写代码”，而是开始真正向一个可用于实际工程任务的 Coding Agent 模型靠近。
会写代码，只是起点。能把任务做完，并且把成本控制在合理范围内，才是更值得关注的能力。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：释然IT杂谈 z释然z
z释然z《Step 5 Preview Coding 实测：从 API 接入到 Linux 实机 Debug，它能把工程任务做完吗？》