sublime text构建系统本质是执行外部命令，不关心运行对象类型，只负责拼接命令、传参并捕获输出；关键要求是生成器须命令行可用且输入输出明确，不支持交互式stdin或状态维持。
构建系统调用代码生成器的本质是执行外部命令
Sublime Text 的构建系统不关心你运行的是编译器、解释器，还是一个 Python 脚本生成器（比如 inferencesh、cookiecutter、自定义的 gen.py），它只负责拼接命令、传参、捕获 stdout/stderr 并展示。关键在于：生成器必须能从命令行直接调用，且输入/输出符合预期。
例如，你想用 inferencesh SDK 生成一个智能体模板，命令可能是：
inferencesh generate --template agent --name my_agent
但 Sublime 构建系统默认工作目录是当前文件所在路径，而 inferencesh 往往需要在项目根目录下运行；同时，它不读取当前打开的文件内容，而是依赖命令行参数。所以不能简单套用 ["python", "$file"] 模式。
如何配置支持参数化调用的构建系统
你需要显式控制命令结构、工作目录和参数来源。常见场景包括：
- 固定模板生成（如每次生成同一种结构）：把完整命令写死在
cmd中 - 动态命名（如根据当前文件名生成对应模块）：用
$file_base_name变量注入 - 交互式参数（如让用户输入名称）：构建系统本身不支持 stdin 输入，需改用
shell_cmd+sh -c或转向 Terminus 插件
以 inferencesh generate 为例，推荐配置如下（保存为 inferencesh_Generate.sublime-build）：
{
"shell_cmd": "cd $project_path && inferencesh generate --template agent --name $file_base_name",
"selector": "source.yaml, source.json, text.plain",
"working_dir": "$project_path",
"file_regex": "^Error: (.*)$"
}
说明：
-
shell_cmd比cmd更适合组合多条 shell 命令，&&确保前一步成功才执行下一步 -
$project_path是 Sublime 的内置变量，指向当前打开的文件夹（即项目根目录），比$file_path更可靠 -
selector设为source.yaml等，是为了让构建系统在打开配置文件时自动激活（而非只绑定到 .py 文件） -
file_regex需按实际错误格式调整；inferencesh报错若含Error:前缀，该正则就能双击跳转
为什么直接运行 python gen.py 可能失败
如果你的生成器是一个本地脚本（如 gen.py），常见问题不是语法错误，而是环境与路径错位：
- Python 解释器找不到：没配
PYTHONPATH，或虚拟环境未激活 → 在构建系统中加"env": {"PYTHONPATH": "$project_path/src"} - 脚本依赖相对路径导入（如
from utils import render）→ 必须确保working_dir是包根目录，否则报ModuleNotFoundError - 脚本需要读取当前文件内容（如解析
schema.json生成代码）→ 构建系统默认不传入文件内容，得用shell_cmd显式传$file参数，例如："shell_cmd": "python $project_path/gen.py $file" - Windows 下空格路径被截断：用引号包裹变量，如
"shell_cmd": "python "$project_path\gen.py" "$file""
容易忽略的三个硬限制
构建系统不是终端模拟器，它对生成器行为有隐性约束：
- 不支持交互式 stdin：所有输入必须提前通过参数或文件提供，
input()会卡住，无回显 - 输出缓冲不可控：Python 默认行缓冲，
print("generating...")可能延迟显示 → 必须加-u参数：["python", "-u", "$project_path/gen.py"] - 无法跨会话复用状态：每次 Ctrl+B 都是全新进程，不能像 REPL 那样保持变量或上下文
真正要跑带交互、状态维持、实时日志的生成流程，得换 Terminus 或用 LSP 启动专用服务 —— 构建系统只适合“输入确定、输出明确、一次完成”的代码生成任务。
