# 输入材料与环境就绪

`finhjb-model-coder` 能否诚实地交付“可运行代码”，取决于两件事：

- 你提供的模型材料
- 对话背后的执行环境

## 最推荐的输入材料

这个 Skill 在你提供下列材料时效果最好：

- 研究问题，以及价值函数代表什么对象
- 唯一状态变量及其定义域
- HJB 方程
- 控制变量及其可行范围
- FOC 或显式策略规则
- 左右边界条件
- smooth-pasting、super-contact 或发行条件
- 参数含义与基准数值

这些材料可以是文字、LaTeX、论文摘录，或它们的混合。

## 支持的模型形态

当前 Skill 建立在一维 FinHJB 上。

最合适的模型形态是：

- 一个连续状态变量
- 一个或多个连续控制变量
- 一个标量价值函数
- 固定边界、边界搜索，或直接边界更新

如果问题明显需要多个状态变量、regime 间耦合的多个价值函数，或 FinHJB 当前还不提供的求解器基础设施，Skill 就应该先停下来。

## 生成代码前必须拦下的硬阻塞

在生成代码前，遇到下面这些情况时 Skill 应该先停下来确认：

- 当前环境还不能导入 `finhjb`
- 只有参数符号，没有可用数值
- 数学表达还不能直接对应到代码，需要先做推导
- 任务要求画图，但图的具体内容没有定义
- 任务同时包含敏感性分析和画图，但交付物结构还不清楚
- 请求了 rescue search，但 Skill 还不知道哪些参数固定、哪些参数可搜索
- 请求了 rescue search，但“希望图/状态长什么样”还没有转成可计算诊断量

## 环境就绪

环境就绪是“可运行交付”的硬前提。

建议规则：

- 仓库任务优先使用仓库 checkout 和仓库自己的 `uv` 环境
- 下游项目任务优先在本地项目中安装 `finhjb`，例如 `uv add finhjb` 或 `pip install finhjb`

最小 smoke test：

```bash
python -c "import finhjb"
```

仓库场景更贴近实际的 smoke test：

```bash
uv run python -c "import finhjb"
```

## Skill 必须显式确认的数值选择

### 差分格式

不要对所有模型都静默默认 `central`。

经验法则：

- 左右边界扩散都不接近 0：优先 `central`
- 左边界附近扩散很小：优先 `forward`
- 右边界附近扩散很小：优先 `backward`

### 边界搜索方法

不要把边界搜索当成隐藏实现细节。

经验法则：

- 1-2 个边界目标且 bracket 可信：先用 `bisection`
- 3 个及以上目标：先用 `hybr` 或其他多维 root solver

如果第一默认值在测试修复闭环里失败，最终实现应该显式升级。

## Rescue Search 需要的额外输入

如果模型已经可运行，但参数校准或边界初值不够可靠，`finhjb-model-coder` 可以切到 `parameter-search rescue mode`。

这时至少还需要明确：

- 哪些参数必须固定
- 哪些参数允许搜索，以及区间和尺度
- 哪些条件是硬约束
- 哪些结果只是软偏好
- 每次求解后要抽取哪些诊断量
- 初始搜索预算应该多大

如果用户只说“希望图更平滑”“结果更像论文”，Skill 不能直接开始搜，必须先把这些要求翻译成明确诊断量。

## 相关页面

- [输出与验证](./finhjb-model-coder-output-and-validation.md)
- [完整整合页](./finhjb-model-coder.md)