vscode snippet 本质是静态文本替换，不理解语义，故 quick_sort 等模板若将边界写死为 0 和 a.size()-1，就需每次手动修改；应改用占位符如 $1、$2 以支持任意子区间调用。
VSCode 插件确实能帮你自动生成标准算法逻辑，但关键在于选对插件、配对场景、避开默认模板的硬伤。
用 quick_sort 这类 snippet 生成算法时，为什么总要手动改边界条件？
VSCode 内置的代码片段（snippet）本质是静态文本替换，不理解语义。比如官方或社区提供的 quick_sort snippet，通常把 l 和 r 写死为 0 和 a.size()-1，但实际调用中你大概率要传入子区间——这导致每次粘贴后都得删掉首尾两行、重写入口调用。
- 真正可用的 snippet 应该把参数留空或用占位符（如
$1），而不是填具体值 - 检查你的 snippet 文件：如果
"body"里出现quick_sort(a, 0, a.size()-1)，就说明它不适合复用 - 推荐修改方式：把最后一行改成
quick_sort(a, $1, $2);，Tab 两次就能填入任意下标
DeepSeek Coder 插件生成排序函数，为啥输出的 partition 逻辑和教科书不一样？
它默认按「稳定+易读」优先生成，不是照搬《算法导论》里的经典双指针。例如会倾向用 std::partition 或三路划分，而非手写 while 循环；对 vector<int>&</int> 类型可能直接返回新数组，而不是原地修改。
- 这不是 bug，是模型对“可用性”的判断：避免越界、减少分支嵌套、适配现代 STL
- 若你明确需要原地快排，提示词里必须写清楚：
// in-place quick sort with Lomuto partition, no STL helpers -
temperature设为0.3时输出更保守；临时调到0.7可能给出更贴近教材的版本，但需人工校验边界
VibeThinker-1.5B 本地跑算法推理，为什么对 DP 题生成的递推式经常漏初值？
它强在多步逻辑链构建，但对初始化这种“非推理性”细节容易忽略——尤其当题目描述没显式说 dp[0] = 1 时，模型倾向于从状态转移出发，跳过定义域起点。
- 这不是模型能力不足，而是训练数据里初值常被当作“常识”省略，没当成必须输出项
- 实操建议：在 prompt 末尾加一句
请显式写出所有 base case 和 dp 数组初始化代码 - 生成后务必检查
dp数组是否 resize、是否赋初值，否则运行时大概率index out of bounds
算法生成不是“抄完就能跑”，真正的省时点在于：把反复调试边界和初始化的过程，换成一次精准 prompt + 两行人工验证。最危险的不是生成错，而是生成得“差不多”，让你误以为可以跳过逻辑审查。
