声明:CSDN是本Blog托管服务提供商。如本文牵涉版权问题,CSDN不承担相关责任,请版权拥有者直接与文章作者联系解决。
1. 你们的项目组使用源代码管理工具了么?
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么?
应该用。ClearQuest太复杂,我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么?
不要用Word写测试用例(Test Case)。应该用一个专门的系统,可以是Test Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站?
要有一个门户网站,用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现,15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么?
应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么?
需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么?
需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么?
应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么?
要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么?
需要。我反对Virtual Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况?
应该反映。但是,应该用Baseline的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么?
应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。
13. 你们的开发人员从项目一开始就加班么?
不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?
不要。Buffer Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间,从95%做到100%好
值得,非常值得。尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。
16. 登记新缺陷时,是否写清了重现步骤?
要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro Steps也需要。
17. 写新代码前会把已知缺陷解决么?
要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么?
必须有定义。Severity要分1、2、3,约定好:蓝屏和Data Lost算Sev 1,Function Error算Sev 2,界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
19. 你们对意见不一的缺陷有三国会议么?
必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登记的人最后关闭的么?
Bug应该由Opener关闭。Dev不能私自关闭Bug。
21. 你们的程序员厌恶修改老的代码么?
厌恶是正常的。解决方法是组织Code Review,单独留出时间来。XP也是一个方法。
22. 你们项目组有Team Morale Activity么?
每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。
23. 你们项目组有自己的Logo么?
要有自己的Logo。至少应该有自己的Codename。
24. 你们的员工有印有公司Logo的T-Shirt么?
要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几次就破破烂烂的。
25. 总经理至少每月参加次项目组会议
要的。要让team member觉得高层关注这个项目。
26. 你们是给每个Dev开一个分支么?
反对。Branch的管理以及Merge的工作量太大,而且容易出错。
27. 有人长期不Check-In代码么?
不可以。对大部分项目来说,最多两三天就应该Check-In。
28. 在Check-In代码时都填写注释了么?
要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。
29. 有没有设定每天Check-In的最后期限?
要的,要明确Check-In Deadline。否则会Build Break。
30. 你们能把所有源码一下子编译成安装文件吗?
要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么?
当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。
32. 你们公司有没有积累一个项目风险列表?
要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。
33. 设计越简单越好
越简单越好。设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
34. 尽量利用现有的产品、技术、代码
千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。
35. 你们会隔一段时间就停下来夯实代码么?
要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。
36. 你们的项目组每个人都写Daily Report么?
要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。
37. 你们的项目经理会发出Weekly Report么?
要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。
38. 你们项目组是否至少每周全体开会一次?
要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
39. 你们项目组的会议、讨论都有记录么?
会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。
40. 其他部门知道你们项目组在干什么么?
要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。
41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。
42. 为项目组建立多个Mailing Group
如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。
43. 每个人都知道哪里可以找到全部的文档么?
应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。
44. 你做决定、做变化时,告诉大家原因了么?
要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。
45. Stay agile and expect change
要这样。需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。
46. 你们有没有专职的软件测试人员?
要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。
47. 你们的测试有一份总的计划来规定做什么和怎么做么?
这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。
48. 你是先写Test Case然后再测试的么?
应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。
49. 你是否会为各种输入组合创建测试用例?
不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。
50. 你们的程序员能看到测试用例么?
要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。
51. 你们是否随便抓一些人来做易用性测试?
要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。
52. 你对自动测试的期望正确么?
别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。
53. 你们的性能测试是等所有功能都开发完才做的么?
不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。
54. 你注意到测试中的杀虫剂效应了么?
虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。
55. 你们项目组中有人能说出产品的当前整体质量情况么?
要有。当老板问起这个产品目前质量如何,Test Lead/Manager应该负责回答。
56. 你们有单元测试么?
单元测试要有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了——可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。
57. 你们的程序员是写完代码就扔过墙的么?
大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法,程序太烂的话,测试有权踢回去。
58. 你们的程序中所有的函数都有输入检查么?
不要。虽然说做输入检查是write secure code的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么?
要有。最好能有统一的error message,然后每个error message都带一个error number。这样,用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因,就像SQL Server的错误那样。同样,ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
60. 你们有统一的代码书写规范么?
要有。Code Convention很多,搞一份来发给大家就可以了。当然,要是有FxCop这种工具来检查代码就更好了。
61. 你们的每个人都了解项目的商业意义么?
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者,或者时不时的告诉team member,这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱,这样就有动力了。平凡的事情也是可以有个崇高的目标的。
62. 产品各部分的界面和操作习惯一致么?
要这样。要让用户觉得整个程序好像是一个人写出来的那样。
63. 有可以作为宣传亮点的Cool Feature么?
要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩盖一些问题。这样,对于客户来说,会感觉产品从质量角度来说还是acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
64. 尽可能缩短产品的启动时间
要这样。软件启动时间(Start-Up time)是客户对性能好坏的第一印象。
65. 不要过于注重内在品质而忽视了第一眼的外在印象
程序员容易犯这个错误:太看重性能、稳定性、存储效率,但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾,协调这些是PM的工作。
66. 你们根据详细产品功能说明书做开发么?
要这样。要有设计才能开发,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的方法。设计的时候千万别钻细节,别钻到数据库、代码等具体实现里面去,那些是后面的事情,一步步来不能着急。
67. 开始开发和测试之前每个人都仔细审阅功能设计么?
要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”
68. 所有人都始终想着The Whole Image么?
要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。
69. Dev工作的划分是单纯纵向或横向的么?
不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。
70. 你们的程序员写程序设计说明文档么?
要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。
71. 你在招人面试时让他写一段程序么?
要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等,既不偏向过于考算法,也不偏向过于考特定的API。
72. 你们有没有技术交流讲座?
要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得,这笔花钱送到外面去培训划算。
73. 你们的程序员都能专注于一件事情么?
要让程序员专注一件事。例如说,一个部门有两个项目和10个人,一种方法是让10个人同时参加两个项目,每个项目上每个人都花50%时间;另一种方法是5个人去项目A,5个人去项目B,每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂,但很多领导实践起来就把属下当成可以任意拆分的资源了。
74. 你们的程序员会夸大完成某项工作所需要的时间么?
会的,这是常见的,尤其会在项目后期夸大做某个change所需要的时间,以次来抵制change。解决的方法是坐下来慢慢磨,磨掉程序员的逆反心理,一起分析,并把估算时间的颗粒度变小。
75. 尽量不要用Virtual Heads
最好不要用Virtual Heads。Virtual heads意味着resource is not secure,shared resource会降低resource的工作效率,容易增加出错的机会,会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人,要强过两个只能投入50%时间和精力的人。我是吃过亏的:7个part time的tester,发现的Bug和干的活,加起来还不如两个full-time的。参见第73条。73条是针对程序员的,75条是针对Resource Manager的。
分享到:
相关推荐
根据给定文件的信息,我们可以提炼出与“2024嵌入式面试资料阿里C++面试面经”相关的几个重要知识点。以下是对这些知识点的详细阐述: ### 1. C++语言基础 #### 1.1 数据类型 C++支持多种数据类型,包括基本数据...
文学翻译的文化传递、语言风格保持与读者接受度提升
,,Phase_Shift_T:基于MATLAB Simulink的移相变压器仿真模型,可实现-25°、-15°……25°的移相。 变压器副边实现36脉波不控整流,变压器网侧电压、阈侧电压以及移相角度可直接设置。 仿真条件:MATLAB Simulink R2015b ,核心关键词: 1. 移相变压器仿真模型 2. MATLAB Simulink 3. 移相 4. 36脉波不控整流 5. 网侧电压 6. 阈侧电压 7. 设置 8. MATLAB Simulink R2015b,MATLAB Simulink中实现宽范围移相与多脉波整流的变压器仿真模型
管理员主要负责填充图书和其类别信息,并对已填充的数据进行维护,包括修改与删除,管理员也需要审核老师注册信息,发布公告信息,管理自助租房信息等。用户信息管理页面,此页面提供给管理员的功能有:用户信息的查询管理,可以删除用户信息、修改用户信息、新增用户信息。商品分类管理页面,此页面提供给管理员的功能有:查看已发布的商品分类数据,修改商品分类,商品分类作废,即可删除。商品信息管理页面,此页面提供给管理员的功能有:根据商品名称进行条件查询,还可以对商品数据进行新增、修改、查询操作等等。商品资讯管理页面,此页面提供给管理员的功能有:查看已发布的商品资讯数据,修改商品资讯,商品资讯作废,即可删除。2 相关技术 3 2.1 SSM框架介绍 3 2.2 B/S结构介绍 3 2.3 Mysql数据库介绍 4 3 系统分析 6 3.1 系统可行性分析 6 3.1.1 技术可行性分析 6 3.1.2 经济可行性分析 6 3.1.3 运行可行性分析 6 3.2 系统性能分析 7 3.2.1 易用性指标 7 3.2.2 可扩展性指标 7 3.2.3 健壮性指标 7 3.2.4 安全性指标 8 3.3 系统流程分
当前资源包含初中高级闯关习题
,,欧姆龙PLC螺丝机程序(含触摸屏程序) 此程序已经实际设备上批量应用,程序成熟可靠,借鉴价值高,程序有注释、非常适合用来欧姆龙plc新手学习,包括欧姆龙plc程序和威纶触摸屏程序。 是新手入门级欧姆龙PLC电气爱好从业人员借鉴和参考经典案列。 ,欧姆龙PLC; 螺丝机程序; 触摸屏程序; 程序成熟可靠; 注释详尽; 新手学习; 经典案例。,欧姆龙PLC螺丝机程序详解:成熟可靠的新手学习经典案例
,,c# mqtt高性能服务器端源代码。 你还在使用第三方服务软件吗?不如试试这个开发框架,助你一臂之力,无限制,无全开源,无版权约束,全是自主开发。 开源框架包括服务器和客户端,支持mqtt3.0及5.0。 可嵌入到自己的服务系统及软件客户端中,不受第三方约束。 你要问我稳定性如何?我能回答的是已经运行了三年有余无任何问题。 如果你要问能接入多少终端,我可以明确回答,不敢往多的说,单节点支持100万并发量无压力。 这是一个关于C# MQTT高性能服务器端源代码的描述。如果我重新表述一下,可以这样说:你是否还在使用第三方服务软件?为什么不尝试一下这个开发框架呢?它可以为你提供强大的支持,没有任何限制,完全开源,没有版权约束,全部都是自主开发的。 这个开源框架包括服务器和客户端,支持MQTT 3.0和5.0协议。你可以将它嵌入到自己的服务系统和软件客户端中,不受第三方的限制。 你可能会问它的稳定性如何。我可以很自信地告诉你,它已经运行了三年多,没有出现任何问题。 如果你想知道它可以接入多少终端,我可以明确地回答,单节点支持100万并发连接,毫不费力。 从这段话中,我们可以提取出以
1.版本:matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点:参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象:计算机,电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
,,matlab程序,复现,基于改进粒子群算法的混合储能系统容量优化,关键词,超级电容,混合储能,粒子群算法。 拿之前问清楚 可以运行看结果,出不 不 ,MATLAB程序; 复现; 改进粒子群算法; 混合储能系统容量优化; 超级电容; 粒子群算法。,MATLAB复现:混合储能系统优化策略研究,基于改进粒子群算法的超级电容容量配置
,,k—medoids 聚类方法的MATLAB源代码,导入数据部分和画图部分已经用中文给出了注释。 这儿选取一个对象叫做mediod来代替上面的中心 的作用,这样的一个medoid就标识了这个类。 ,k-medoids聚类方法; MATLAB源代码; 导入数据部分; 画图部分; 对象; medoid; 类标识。,基于K-Medoids聚类方法的MATLAB源代码及中文注释解析
自驾游中如何保护自然环境
qt 一个基于Qt Creator(qt,C++)实现中国象棋人机对战.
项目资源包含:可运行源码+sql文件+文档; python3.7+django+mysql5.7+vue 适用人群:学习不同技术领域的小白或进阶学习者;可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 项目具有较高的学习借鉴价值,也可拿来修改、二次开发。 有任何使用上的问题,欢迎随时与博主沟通,博主看到后会第一时间及时解答。 系统是一个很好的项目,结合了后端服务(django)和前端用户界面(Vue.js)技术,实现了前后端分离。 当人们打开系统的网址后,首先看到的就是首页界面。在这里,人们能够看到系统的导航条,通过导航条导航进入各功能展示页面进行操作。在个人中心页面可以输入个人信息进行更新信息操作,还可以对我的订单、我的地址和我的收藏进行详细操作。 管理员进入主页面,主要功能包括对首页、个人中心、用户管理、商品类别管理、热卖商品管理、投诉建议、系统管理、订单管理等进行操作。用户进入系统后台,主要功能包括对个人中心和我的收藏管理进行操作。
漫画作品与节日庆典结合
自驾游中的手机APP推荐
,,该套程序是电芯上料机,空料仓和满料仓都是步进电机,搬运模组是松下A6脉冲控制伺服电机,该套程序是已经在量产程序,图四是上料机设备全局图,标准程序框架,其他设备也可套用。 ,电芯上料机; 步进电机; 满料仓; 松下A6脉冲控制伺服电机; 标准程序框架; 设备全局图; 其他设备通用,电芯上料机程序:松下A6伺服电机驱动的步进式料仓管理系统
1.版本:matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点:参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象:计算机,电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
,,Matlab代码-基于拉格朗日电力系统参数辨识 对电力系统中存在多个不良参数进行辨识,以IEEE14节点系统进行仿真验证。 ,基于拉格朗日; 电力系统参数辨识; 不良参数辨识; IEEE14节点系统仿真验证。,基于拉格朗日算法的电力系统多参数辨识及IEEE14节点仿真验证
它利用图像预处理、车牌字符分割、字符识别等相关处理技术,对小型车辆的蓝底白字车牌进行车牌号识别。车牌定位是利用HSV色彩定位法,这种方法可大大缩短后续处理时间,字符分割采用阈值限定分割,字符识别则采用模板匹配法。在拍摄角度不过度倾斜情况下识别精度较高,白天照片预处理、分割效果较晚间好。
该文档围绕 DeepSeek 和 AIGC 展开,介绍了 DeepSeek-R1 模型的技术特性、AIGC 的概念、应用及相关工具的选择。 适用人群:对人工智能、AIGC 技术感兴趣的初学者,想要了解行业动态的专业人士,以及寻求提升工作效率、探索创新应用的企业和个人。包括但不限于 AI 从业者、内容创作者、教育工作者、科研人员、电商从业者、传媒工作者、游戏开发者等。 使用场景:在科研领域,DeepSeek-R1 可用于复杂问题求解、实验设计和论文撰写;教育场景中,能辅助知识理解、解答问题,还可作为教学工具锻炼学生逻辑思维。内容创作方面,AIGC 工具能生成文本、图像、音频和视频,满足不同创作需求。电商行业利用 AIGC 制作商品 3D 模型、虚拟主播,提升购物体验和直播带货效率。新闻传媒行业借助 AIGC 提高采编效率、打造 AI 主播。影视和游戏行业,AIGC 可用于剧本创作、角色生成、场景拓展等。