同一个参数，界面上能改，代码里也能改，两处同时存在的时候，以哪个为准？这个问题不搞清楚，策略行为会莫名其妙地漂移。

先说结论：代码是唯一的事实来源，界面只能作为临时的实验手段。原因是可追溯。代码里的参数跟着文件走，改了能留痕、能回滚、能和回测版本对应；界面上的改动往往只存在运行实例里，重启之后可能就丢了，事后没人说得清当时跑的是什么。

那界面上为什么还留参数入口。它是为了方便你快速试几个值，看行为变化，不用改文件重启。这种用法没问题，前提是你试完之后把结论写回代码，而不是让临时值一直在跑。

有个坑要提醒：有些平台的界面参数会覆盖代码里的默认值，而且是持久化保存的。你以为改了代码就生效，实际被界面上的旧值盖住了。症状是代码怎么看都对，行为就是不对。排查时先看界面上的当前值。

建议的做法是给每个参数写清楚三件事：含义、取值范围、默认值。改参数时一次只改一个，改完记录结果。这个习惯能让你在面对几十个参数时不至于迷失。

最后一句，参数越少越好。第一版策略留三个以内的可调参数，剩下的全部写死。参数多不等于策略强，只等于你更容易骗自己。

还有一种更隐蔽的不一致：代码里改了参数，但策略实例没有重新加载。界面上看着是新值，跑的还是旧逻辑。改完参数一定要重启策略，并且用日志打印一次当前参数值，确认生效。

把这套流程固定下来：改代码、重启、看日志确认参数、跑一笔小单验证行为。四步走完，才算这次改动真的落地了。

股票/量化开户欢迎找我！满足条件股票佣金万0.854、etf 可转债佣金万0.5、国债逆回购一折（百万分之一）！期权1.8元一张全包价！量化软件QMT+ptrade免费使用！还有888、999资金靓号等你选！