1. DevExpress DateEdit 周名显示异常到底卡在哪DevExpress 的 DateEdit 控件在 WinForms 项目里出镜率很高皮肤好看、下拉日历顺手很多做 ERP、MES、排班系统的朋友都爱用它。但只要你把日期格式设成带周名的样式比如yyyy-MM-dd dddd或者dddd大概率会撞上一个很迷惑的现象本该显示「星期一」「星期二」的位置只渲染出一个「星」字或者干脆变成「星」加一个空白。这个问题在中文 Windows 环境下尤其常见英文环境反而不容易复现所以很多人第一次遇到会以为是皮肤或者字体的问题折腾半天没头绪。先把结论说清楚DateEdit 本身能做什么、适合谁。它是 DevExpress.XtraEditors 命名空间下的日期编辑控件支持掩码输入、下拉日历、日期范围限制、自定义格式。适合做业务系统里所有需要选日期的表单场景。周名显示异常不是控件坏了而是它内部取「星期几」的缩写时拿到的AbbreviatedDayNames数组和中文DateTimeFormatInfo的默认值对不上导致只截出了一个「星」字。我试过在同一个项目里对比把系统区域切成英文dddd正常显示 Monday切回中文立刻变「星」。这就说明问题出在DateTimeFormatInfo的本地化数据上而不是 Mask 写错了。很多人第一反应是去改Properties.Mask.EditMask改成dddd或者ddd结果发现下拉日历里的星期表头还是「星」因为日历表头和编辑框走的是两套格式化逻辑。所以排查要分两条线一条是编辑框里显示的文本受Properties.Mask、Properties.DisplayFormat、Properties.EditFormat影响另一条是下拉日历 PopupDateEditForm 里的星期表头受DateEditCalendar内部的DateEditInfoArgs.DateFormat影响。只改前者日历表头依旧错只改后者编辑框可能还是「星」。真正干净的解法是让两者都拿到正确的AbbreviatedDayNames。这篇就按「先定位、再配置、后验证」的顺序走给你能直接复制的属性配置和一段可编译的日历格式化代码。如果你只是想快速让编辑框显示对第三节的 JSON/属性片段就够如果你要连下拉日历一起修第四节的验证步骤会带你确认两处都正常。整个过程不需要改 DevExpress 源码也不需要重新编译官方 DLL用标准发布包就能落地。2. TaoToken 前置把模型对话和接入文档准备好排查这类控件问题时我习惯把「查文档」和「问模型」两条路都铺好。DevExpress 的 API 文档更新频繁不同大版本比如 22.1 和 23.2里DateEditCalendar的受保护方法签名可能微调光靠记忆容易踩坑。这时候用 TaoToken 的模型对话能力去核对 API 名称、参数列表比翻半天本地帮助文件快得多。TaoToken 在这里扮演的是一个统一的模型调用入口。你可以把它理解成一个「模型网关」不管底层用的是哪家模型你拿到的都是一套兼容的接口地址和 Key代码里改 Base URL 就能切换。对做 .NET 桌面开发的人来说它的价值在于——你可以在写代码的间隙直接把报错信息、控件类名、目标格式丢给模型让它给出候选的 API 调用方式然后再回 IDE 里验证。前置准备其实就三样东西一个可用的 API Key、正确的 Base URL、以及你要用的 Model ID。这三件套在后面的配置里会反复出现尤其是接 Claude Code 或者 Cline 这类编码工具时缺一个都会报错。Base URL 统一用https://taotoken.net/api注意这个地址后面不要加多余的路径很多 401 就是因为手滑多写了/v1或者结尾斜杠。拿 Key 的入口在控制台里登录后进 API Keys 页面新建即可。如果你只是偶尔问几个 API 问题用按量计费的模型对话就够如果你打算长期让编码助手挂在项目里跑那 Coding Plan 更划算额度稳定、不用每次手动续。文档页里有各语言的最小调用示例.NET 这边用 HttpClient 直接 POST 就行不需要额外 SDK。有一点要提醒TaoToken 是模型调用入口不是 DevExpress 的替代品也不是让你把生产数据库直连出去。它的定位是帮你查资料、核对 API、生成配置片段。控件本身的修复还是要在你的 Visual Studio 项目里完成。把这条边界守住后面所有操作都是安全的。准备好之后你可以先在模型对话里问一句「DevExpress DateEdit 中文环境 dddd 只显示星字怎么修」看看返回的思路和这篇是否一致顺便验证你的 Key 和 Base URL 是通的。通了再往下走省得配置到一半发现是网络或鉴权问题。3. 可复制配置Mask、FormatType 与日历格式化三件套这一节是核心给你能直接粘进项目的配置。先讲编辑框层面的属性再讲下拉日历层面的代码。两者配合周名才会在编辑框和日历表头同时正确。编辑框层面关键属性有三个Properties.Mask.MaskType、Properties.Mask.EditMask、Properties.DisplayFormat。如果你只是想让用户看到带周名的日期最省事的是用 DisplayFormat而不是死磕 Mask。Mask 更适合强制输入格式DisplayFormat 只管显示。下面这段是设计器里生成的属性配置等价于你在 Properties 面板里点出来的结果// 编辑框显示2024-06-03 星期一 dateEdit1.Properties.DisplayFormat.FormatString yyyy-MM-dd dddd; dateEdit1.Properties.DisplayFormat.FormatType DevExpress.Utils.FormatType.DateTime; dateEdit1.Properties.EditFormat.FormatString yyyy-MM-dd; dateEdit1.Properties.EditFormat.FormatType DevExpress.Utils.FormatType.DateTime; dateEdit1.Properties.Mask.MaskType DevExpress.XtraEditors.Mask.MaskType.DateTime; dateEdit1.Properties.Mask.EditMask yyyy-MM-dd; dateEdit1.Properties.Mask.UseMaskAsDisplayFormat false;注意UseMaskAsDisplayFormat要设成 false否则 Mask 会覆盖 DisplayFormat周名又被吃掉。这是很多人改了 DisplayFormat 却没效果的根因。如果你用配置文件管理这些属性可以写成 JSON 片段路径和字段名按你项目实际结构调整{ DateEdit: { DisplayFormat: { FormatType: DateTime, FormatString: yyyy-MM-dd dddd }, EditFormat: { FormatType: DateTime, FormatString: yyyy-MM-dd }, Mask: { MaskType: DateTime, EditMask: yyyy-MM-dd, UseMaskAsDisplayFormat: false } } }编辑框搞定后下拉日历的星期表头还得单独处理。日历内部用的是AbbreviatedDayNames中文环境下默认值带「星期」前缀被截断后就剩「星」。解法是继承DateEditCalendar重写CreateInfoArgs把AbbreviatedDayNames换成单字数组。下面这段可直接编译using System.Globalization; using DevExpress.XtraEditors.Controls; using DevExpress.XtraEditors.Repository; using DevExpress.XtraEditors.ViewInfo; public class ZhDateEditCalendar : DateEditCalendar { public ZhDateEditCalendar(RepositoryItemDateEdit item, object editDate) : base(item, editDate) { } protected override DateEditInfoArgs CreateInfoArgs() { DateEditInfoArgs info base.CreateInfoArgs(); var fmt (DateTimeFormatInfo)info.DateFormat.Clone(); fmt.AbbreviatedDayNames new[] { 日, 一, 二, 三, 四, 五, 六 }; info.DateFormat fmt; return info; } }然后让 DateEdit 的下拉窗体返回这个日历。继承 DateEdit 并重写CreatePopupFormusing DevExpress.XtraEditors; using DevExpress.XtraEditors.Popup; public class ZhDateEdit : DateEdit { protected override PopupBaseForm CreatePopupForm() { return new ZhPopupDateEditForm(this); } } public class ZhPopupDateEditForm : PopupDateEditForm { public ZhPopupDateEditForm(ZhDateEdit edit) : base(edit) { } protected override DateEditCalendar CreateCalendar() { return new ZhDateEditCalendar(OwnerEdit.Properties, OwnerEdit.EditValue); } }用的时候把工具箱里的 DateEdit 换成ZhDateEdit或者代码里new ZhDateEdit()。这套写法不改官方 DLL升级 DevExpress 版本时只要这几个受保护方法签名没变就能继续用。三件套齐了DisplayFormat 管编辑框、Mask 管输入、日历子类管表头。4. 验证请求与成功结果逐步确认周名渲染正确配置写完别急着收工按下面步骤逐条验证确保编辑框和日历两处都对。第一步编译项目。如果CreateInfoArgs或CreateCalendar报「没有可重写的合适方法」说明你的 DevExpress 版本里方法签名变了去对象浏览器里搜DateEditCalendar确认返回类型和参数。这是版本差异最常见的坑。第二步拖一个ZhDateEdit到窗体设好 DisplayFormat 为yyyy-MM-dd dddd运行。编辑框里应该显示类似「2024-06-03 星期一」。如果还是「星」检查UseMaskAsDisplayFormat是不是 true或者 DisplayFormat 被 Mask 覆盖了。第三步点开下拉日历看顶部星期表头。正确结果是「日 一 二 三 四 五 六」七个单字而不是「星 星 星」。如果表头没变确认你 new 的是ZhDateEdit而不是原生DateEdit因为只有前者才会返回自定义 PopupForm。第四步切换几个日期确认周名跟着变。比如选到周日编辑框显示「星期日」日历表头高亮在「日」上。这一步能验证AbbreviatedDayNames的索引顺序和DayOfWeek枚举一致周日0。第五步如果你用 TaoToken 的模型对话辅助排查可以把报错原文贴进去问。比如「DateEditCalendar CreateInfoArgs 返回类型不匹配」模型会提示你检查 DevExpress 版本。验证模型是否正常直接进模型对话发一条消息即可返回正常说明 Key 和 Base URL 没问题。成功的结果长这样编辑框2024-06-03 星期一下拉日历表头日 一 二 三 四 五 六切换日期无异常无异常弹窗。到这一步周名显示问题就算彻底解决了。如果你还想让英文环境也兼容可以在CreateInfoArgs里判断CultureInfo.CurrentCulture.Name只在中文时替换数组其他语言保持默认。5. 本篇常见错排查401、local proxy failed 与 OAuth 报错排查过程中除了控件本身的错接模型工具时也会撞到几类典型报错。这里对照真实错误信息给你定位思路。401 Unauthorized最常见。原因通常是 Key 没填、Key 过期、或者 Base URL 写错。检查三件套——Base URL 用https://taotoken.net/apiKey 从控制台 API Keys 页面复制Model ID 填你实际要用的模型名。三者任一不对都会 401。注意 Base URL 结尾不要加/v1也不要加斜杠。local proxy failed这个报错一般出现在你本地配了代理工具、或者环境变量里残留了HTTP_PROXY。先检查系统环境变量把HTTP_PROXY、HTTPS_PROXY清掉再试。如果你用的是 Cline、Claude Code 这类工具它们可能读了自己的配置文件去设置里把代理项关掉。reading choices相关报错通常是返回体解析失败原因可能是 Model ID 写错导致返回了错误结构或者请求体里stream参数和客户端预期不一致。把 Model ID 核对一遍再确认请求 JSON 里字段名拼写正确。OAuth 报错出现在 Claude Code 或 Codex 这类需要登录态的工具里。如果你用 API Key 方式接入就不该走 OAuth 流程。检查工具配置里是不是选了「OAuth 登录」而不是「API Key」。切到 API Key 模式填 Base URL 和 Key 即可。如果你用 CC Switch、Cline MCP 或 Codex 的auth.json记住三件套必须写全Base URL、Key、Model ID。缺任何一个都会鉴权失败。auth.json里字段名按工具文档来别自己造字段。改完重启工具再试。控件侧的错也顺带列一下CreateInfoArgs报签名不匹配——查版本日历表头没变——确认 new 的是子类编辑框还是「星」——查UseMaskAsDisplayFormat。这几条覆盖了九成场景。6. 继续深入把配置沉淀成可复用组件修好一个 DateEdit 只是开始。实际项目里往往有几十个日期输入框逐个改属性不现实。建议把ZhDateEdit做成一个用户控件或者项目内的基础控件库统一设好 DisplayFormat、Mask 和日历子类其他窗体直接拖这个控件用。这样以后换皮肤、改格式只动一处。如果你还想让模型帮你生成更多控件的格式化配置可以继续用 TaoToken 的模型对话把控件类名和目标格式丢进去让它出候选代码再回 IDE 验证。长期做编码和 Agent 任务的话Coding Plan 的额度更稳适合挂在项目里持续用。接入文档里有各语言示例照着改 Base URL 和 Key 就能跑。最后留一个实用技巧在CreateInfoArgs里加个缓存别每次打开日历都 clone 一遍DateTimeFormatInfo日期选择频繁的表单能省一点开销。改动不大但用起来更顺。
TaoToken 实战：DevExpress DateEdit 控件日期周名显示异常排查与配置
1. DevExpress DateEdit 周名显示异常到底卡在哪DevExpress 的 DateEdit 控件在 WinForms 项目里出镜率很高皮肤好看、下拉日历顺手很多做 ERP、MES、排班系统的朋友都爱用它。但只要你把日期格式设成带周名的样式比如yyyy-MM-dd dddd或者dddd大概率会撞上一个很迷惑的现象本该显示「星期一」「星期二」的位置只渲染出一个「星」字或者干脆变成「星」加一个空白。这个问题在中文 Windows 环境下尤其常见英文环境反而不容易复现所以很多人第一次遇到会以为是皮肤或者字体的问题折腾半天没头绪。先把结论说清楚DateEdit 本身能做什么、适合谁。它是 DevExpress.XtraEditors 命名空间下的日期编辑控件支持掩码输入、下拉日历、日期范围限制、自定义格式。适合做业务系统里所有需要选日期的表单场景。周名显示异常不是控件坏了而是它内部取「星期几」的缩写时拿到的AbbreviatedDayNames数组和中文DateTimeFormatInfo的默认值对不上导致只截出了一个「星」字。我试过在同一个项目里对比把系统区域切成英文dddd正常显示 Monday切回中文立刻变「星」。这就说明问题出在DateTimeFormatInfo的本地化数据上而不是 Mask 写错了。很多人第一反应是去改Properties.Mask.EditMask改成dddd或者ddd结果发现下拉日历里的星期表头还是「星」因为日历表头和编辑框走的是两套格式化逻辑。所以排查要分两条线一条是编辑框里显示的文本受Properties.Mask、Properties.DisplayFormat、Properties.EditFormat影响另一条是下拉日历 PopupDateEditForm 里的星期表头受DateEditCalendar内部的DateEditInfoArgs.DateFormat影响。只改前者日历表头依旧错只改后者编辑框可能还是「星」。真正干净的解法是让两者都拿到正确的AbbreviatedDayNames。这篇就按「先定位、再配置、后验证」的顺序走给你能直接复制的属性配置和一段可编译的日历格式化代码。如果你只是想快速让编辑框显示对第三节的 JSON/属性片段就够如果你要连下拉日历一起修第四节的验证步骤会带你确认两处都正常。整个过程不需要改 DevExpress 源码也不需要重新编译官方 DLL用标准发布包就能落地。2. TaoToken 前置把模型对话和接入文档准备好排查这类控件问题时我习惯把「查文档」和「问模型」两条路都铺好。DevExpress 的 API 文档更新频繁不同大版本比如 22.1 和 23.2里DateEditCalendar的受保护方法签名可能微调光靠记忆容易踩坑。这时候用 TaoToken 的模型对话能力去核对 API 名称、参数列表比翻半天本地帮助文件快得多。TaoToken 在这里扮演的是一个统一的模型调用入口。你可以把它理解成一个「模型网关」不管底层用的是哪家模型你拿到的都是一套兼容的接口地址和 Key代码里改 Base URL 就能切换。对做 .NET 桌面开发的人来说它的价值在于——你可以在写代码的间隙直接把报错信息、控件类名、目标格式丢给模型让它给出候选的 API 调用方式然后再回 IDE 里验证。前置准备其实就三样东西一个可用的 API Key、正确的 Base URL、以及你要用的 Model ID。这三件套在后面的配置里会反复出现尤其是接 Claude Code 或者 Cline 这类编码工具时缺一个都会报错。Base URL 统一用https://taotoken.net/api注意这个地址后面不要加多余的路径很多 401 就是因为手滑多写了/v1或者结尾斜杠。拿 Key 的入口在控制台里登录后进 API Keys 页面新建即可。如果你只是偶尔问几个 API 问题用按量计费的模型对话就够如果你打算长期让编码助手挂在项目里跑那 Coding Plan 更划算额度稳定、不用每次手动续。文档页里有各语言的最小调用示例.NET 这边用 HttpClient 直接 POST 就行不需要额外 SDK。有一点要提醒TaoToken 是模型调用入口不是 DevExpress 的替代品也不是让你把生产数据库直连出去。它的定位是帮你查资料、核对 API、生成配置片段。控件本身的修复还是要在你的 Visual Studio 项目里完成。把这条边界守住后面所有操作都是安全的。准备好之后你可以先在模型对话里问一句「DevExpress DateEdit 中文环境 dddd 只显示星字怎么修」看看返回的思路和这篇是否一致顺便验证你的 Key 和 Base URL 是通的。通了再往下走省得配置到一半发现是网络或鉴权问题。3. 可复制配置Mask、FormatType 与日历格式化三件套这一节是核心给你能直接粘进项目的配置。先讲编辑框层面的属性再讲下拉日历层面的代码。两者配合周名才会在编辑框和日历表头同时正确。编辑框层面关键属性有三个Properties.Mask.MaskType、Properties.Mask.EditMask、Properties.DisplayFormat。如果你只是想让用户看到带周名的日期最省事的是用 DisplayFormat而不是死磕 Mask。Mask 更适合强制输入格式DisplayFormat 只管显示。下面这段是设计器里生成的属性配置等价于你在 Properties 面板里点出来的结果// 编辑框显示2024-06-03 星期一 dateEdit1.Properties.DisplayFormat.FormatString yyyy-MM-dd dddd; dateEdit1.Properties.DisplayFormat.FormatType DevExpress.Utils.FormatType.DateTime; dateEdit1.Properties.EditFormat.FormatString yyyy-MM-dd; dateEdit1.Properties.EditFormat.FormatType DevExpress.Utils.FormatType.DateTime; dateEdit1.Properties.Mask.MaskType DevExpress.XtraEditors.Mask.MaskType.DateTime; dateEdit1.Properties.Mask.EditMask yyyy-MM-dd; dateEdit1.Properties.Mask.UseMaskAsDisplayFormat false;注意UseMaskAsDisplayFormat要设成 false否则 Mask 会覆盖 DisplayFormat周名又被吃掉。这是很多人改了 DisplayFormat 却没效果的根因。如果你用配置文件管理这些属性可以写成 JSON 片段路径和字段名按你项目实际结构调整{ DateEdit: { DisplayFormat: { FormatType: DateTime, FormatString: yyyy-MM-dd dddd }, EditFormat: { FormatType: DateTime, FormatString: yyyy-MM-dd }, Mask: { MaskType: DateTime, EditMask: yyyy-MM-dd, UseMaskAsDisplayFormat: false } } }编辑框搞定后下拉日历的星期表头还得单独处理。日历内部用的是AbbreviatedDayNames中文环境下默认值带「星期」前缀被截断后就剩「星」。解法是继承DateEditCalendar重写CreateInfoArgs把AbbreviatedDayNames换成单字数组。下面这段可直接编译using System.Globalization; using DevExpress.XtraEditors.Controls; using DevExpress.XtraEditors.Repository; using DevExpress.XtraEditors.ViewInfo; public class ZhDateEditCalendar : DateEditCalendar { public ZhDateEditCalendar(RepositoryItemDateEdit item, object editDate) : base(item, editDate) { } protected override DateEditInfoArgs CreateInfoArgs() { DateEditInfoArgs info base.CreateInfoArgs(); var fmt (DateTimeFormatInfo)info.DateFormat.Clone(); fmt.AbbreviatedDayNames new[] { 日, 一, 二, 三, 四, 五, 六 }; info.DateFormat fmt; return info; } }然后让 DateEdit 的下拉窗体返回这个日历。继承 DateEdit 并重写CreatePopupFormusing DevExpress.XtraEditors; using DevExpress.XtraEditors.Popup; public class ZhDateEdit : DateEdit { protected override PopupBaseForm CreatePopupForm() { return new ZhPopupDateEditForm(this); } } public class ZhPopupDateEditForm : PopupDateEditForm { public ZhPopupDateEditForm(ZhDateEdit edit) : base(edit) { } protected override DateEditCalendar CreateCalendar() { return new ZhDateEditCalendar(OwnerEdit.Properties, OwnerEdit.EditValue); } }用的时候把工具箱里的 DateEdit 换成ZhDateEdit或者代码里new ZhDateEdit()。这套写法不改官方 DLL升级 DevExpress 版本时只要这几个受保护方法签名没变就能继续用。三件套齐了DisplayFormat 管编辑框、Mask 管输入、日历子类管表头。4. 验证请求与成功结果逐步确认周名渲染正确配置写完别急着收工按下面步骤逐条验证确保编辑框和日历两处都对。第一步编译项目。如果CreateInfoArgs或CreateCalendar报「没有可重写的合适方法」说明你的 DevExpress 版本里方法签名变了去对象浏览器里搜DateEditCalendar确认返回类型和参数。这是版本差异最常见的坑。第二步拖一个ZhDateEdit到窗体设好 DisplayFormat 为yyyy-MM-dd dddd运行。编辑框里应该显示类似「2024-06-03 星期一」。如果还是「星」检查UseMaskAsDisplayFormat是不是 true或者 DisplayFormat 被 Mask 覆盖了。第三步点开下拉日历看顶部星期表头。正确结果是「日 一 二 三 四 五 六」七个单字而不是「星 星 星」。如果表头没变确认你 new 的是ZhDateEdit而不是原生DateEdit因为只有前者才会返回自定义 PopupForm。第四步切换几个日期确认周名跟着变。比如选到周日编辑框显示「星期日」日历表头高亮在「日」上。这一步能验证AbbreviatedDayNames的索引顺序和DayOfWeek枚举一致周日0。第五步如果你用 TaoToken 的模型对话辅助排查可以把报错原文贴进去问。比如「DateEditCalendar CreateInfoArgs 返回类型不匹配」模型会提示你检查 DevExpress 版本。验证模型是否正常直接进模型对话发一条消息即可返回正常说明 Key 和 Base URL 没问题。成功的结果长这样编辑框2024-06-03 星期一下拉日历表头日 一 二 三 四 五 六切换日期无异常无异常弹窗。到这一步周名显示问题就算彻底解决了。如果你还想让英文环境也兼容可以在CreateInfoArgs里判断CultureInfo.CurrentCulture.Name只在中文时替换数组其他语言保持默认。5. 本篇常见错排查401、local proxy failed 与 OAuth 报错排查过程中除了控件本身的错接模型工具时也会撞到几类典型报错。这里对照真实错误信息给你定位思路。401 Unauthorized最常见。原因通常是 Key 没填、Key 过期、或者 Base URL 写错。检查三件套——Base URL 用https://taotoken.net/apiKey 从控制台 API Keys 页面复制Model ID 填你实际要用的模型名。三者任一不对都会 401。注意 Base URL 结尾不要加/v1也不要加斜杠。local proxy failed这个报错一般出现在你本地配了代理工具、或者环境变量里残留了HTTP_PROXY。先检查系统环境变量把HTTP_PROXY、HTTPS_PROXY清掉再试。如果你用的是 Cline、Claude Code 这类工具它们可能读了自己的配置文件去设置里把代理项关掉。reading choices相关报错通常是返回体解析失败原因可能是 Model ID 写错导致返回了错误结构或者请求体里stream参数和客户端预期不一致。把 Model ID 核对一遍再确认请求 JSON 里字段名拼写正确。OAuth 报错出现在 Claude Code 或 Codex 这类需要登录态的工具里。如果你用 API Key 方式接入就不该走 OAuth 流程。检查工具配置里是不是选了「OAuth 登录」而不是「API Key」。切到 API Key 模式填 Base URL 和 Key 即可。如果你用 CC Switch、Cline MCP 或 Codex 的auth.json记住三件套必须写全Base URL、Key、Model ID。缺任何一个都会鉴权失败。auth.json里字段名按工具文档来别自己造字段。改完重启工具再试。控件侧的错也顺带列一下CreateInfoArgs报签名不匹配——查版本日历表头没变——确认 new 的是子类编辑框还是「星」——查UseMaskAsDisplayFormat。这几条覆盖了九成场景。6. 继续深入把配置沉淀成可复用组件修好一个 DateEdit 只是开始。实际项目里往往有几十个日期输入框逐个改属性不现实。建议把ZhDateEdit做成一个用户控件或者项目内的基础控件库统一设好 DisplayFormat、Mask 和日历子类其他窗体直接拖这个控件用。这样以后换皮肤、改格式只动一处。如果你还想让模型帮你生成更多控件的格式化配置可以继续用 TaoToken 的模型对话把控件类名和目标格式丢进去让它出候选代码再回 IDE 验证。长期做编码和 Agent 任务的话Coding Plan 的额度更稳适合挂在项目里持续用。接入文档里有各语言示例照着改 Base URL 和 Key 就能跑。最后留一个实用技巧在CreateInfoArgs里加个缓存别每次打开日历都 clone 一遍DateTimeFormatInfo日期选择频繁的表单能省一点开销。改动不大但用起来更顺。
