解决方案编写基本思路.docx
- 文档编号:17420074
- 上传时间:2023-07-25
- 格式:DOCX
- 页数:15
- 大小:23.42KB
解决方案编写基本思路.docx
《解决方案编写基本思路.docx》由会员分享,可在线阅读,更多相关《解决方案编写基本思路.docx(15页珍藏版)》请在冰点文库上搜索。
解决方案编写基本思路
解决方案编写基本思路
篇一:
如何写方案
在公司作为一名售前工程师会有大量的方案策划落到头上,这些方案里小的有几十万,大的有上千万。
如何写好方案一直是我们很关注的事情。
沟通是必要的,那首先要明白相互的倾向,这样就便于达成一致,售前支持也不列外,普通大众到什么范围
而我们基本上都是在方案提交前一两天接到写方案的任务,也不能不做,只好心里大骂一句,骂完后就打电话搞清楚别人的要求,边问就边构思整个方案的推导思路和结构提纲。
所以我其实也特别紧张,注意力也特别集中,大脑也高速反应,基本上几分钟电话或面谈完思路基本就有了,然后该干嘛干嘛,找一些零散的小时间把思路不断推导一下,然后到了一个比较安静和完整的时间前才开始写,这个时候基本上要写的话都想清楚了,只需要不断敲字,敲字的时候也是注意力也特别集中,大脑也高速反应,越写思路越开,很快也就完工了。
写方案不难,知道怎么写才难。
关于写方案我总结一点,结构化地去组织你的思想。
有结构就有思路,有思路就有方案。
另外真正写方案的人,对自己写过的方案是永远不会满意的,只有这样,每次都会进步一点点,解决方案水平质量就会随公司能力不断增长。
当然我曾经问过很多人,你到底为什么写不出好的方案呢?
基本上原因可以归为四类:
第一种是没有体系
一旦用户要求提供关于网络的方案,很多人大脑是一片空白,完全不知道从哪里下手。
很多人说起自己的产品来,好像知道不少卖点,不过真要写出来,又觉得无从下笔。
这种情况一般是写方案者不熟悉自己产品体系造成的,知道一两个甚至更多的产品卖点不难,但难就难在成体系,知识就是成体系的点构成的,而不是一句离散的说法构成的。
因为我们这个行业从业人员说句不客气的话,大部分对所销售实施的管理系统并
没有很深入的研究,都是半路出家,从头开始,在学习过程中熟悉,在熟悉过程中领悟。
所以一下子去驾驭一个整体方案是很痛苦的。
只有当一个人对一个产品思路有体系以后,才能够写出完整的方案,否则就是一个单元也要费尽脑汁。
所以一个人要想写好一个方案,首先要把自己产品的来龙去脉,功能模块,适应领域,典型客户实施情况有一个全面的了解,这样才能建立一个完整的知识体系,然后逐步补充竞争对手知识和一些技术性知识,不断深化自己的知识体系。
第二种是没有思路
有很多用户看多了模板化的方案以后,想看一些针对他们自己的业务的个性化内容,这个时候有的人按照标准方案模板修改还勉强能对付,但对于个性化内容针对性方案就速手无策了。
这种情况从根本上讲还是写方案者不熟悉企业业务造成的,写方案,特别是针对性方案不仅仅要求了解企业的需求,而且要知道这些需求是在何种业务需求下产生的,用户提出这样的要求到底想解决什么问题,把这个问题找出来,一般针对性解决思路就有了,有了思路,自然可以很好的写方案。
所以一个人要写好方案,还需要了解下客户的业务,了解业务最有效的方法就是亲自做几次详尽的业务调研,有了业务调研做基础,在调研过程中把握用户关注,重难点问题,自然可以比较好的确定方案的个性化内容思路。
解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。
第三种是没有素材
一般不经常写方案的人,在写一个方案的时候,即使有想法,有思路,但往往也会很累,就是因为缺少足够的素材。
很多项目现在都是投标,不同用户可能有不同投标的要求,这样很难用一个方案去适应所有的用户,因此在每个方案中都有一些需要准备的内容。
这些内容基本上是通用的,但如果没有足够积累每次编制方案就需要花费大量时间去准备,造成方案完成周期过长。
所以写好方案必须具备这三个条件,第一方案编制者对企业业务要很熟悉,或者有相关业务调研经验,第二方案编制者对产品非常熟悉,至少对自己产品功能模
块作用很清楚,第三方案编制者手上有大量可公用的素材库。
第四种是没有层次
很多人刚和用户接触没有多久,为了表现自己对客户的重视,马上表示要提供方案,当然有的客户刚刚开始选型,也不知道到底要什么搞,也要供应商马上提供一个方案。
结果拍胸脯容易,写方案难,自己写不出来只好求公司,公司没有安排专人了解情况,只好按模板制作一个,用户一看几个供应商内容都差不多,觉得不好,又总结出一些个性化要求,于是大家有开始折腾第二轮方案。
其实方案编制在不同阶段有不同策略,不要轻易提供方案。
刚开始接触是可以提供项目合作建议书,类似可行性报告,项目需要考察软件技术,可以提供标准的产品技术白皮书,到了经过售前调研,有所准备,在演示前后阶段和其它竞争对手刺刀见红的时候,才在知己知彼的基础上提供解决方案或者投标书。
过早提供方案只能匆匆了事,时间紧急,质量自然不高,自然也就觉得方案难写。
想急就又能解决问题的事情,本来就是一般人做不来的。
方案想要写得好,一定要用心,用心就一定要耗时间,指望用几个小时写出一个高质量的方案是不可能的。
如果你做了精心调研,你写不出一个好方案唯一缺的是技巧。
写方案是一种技巧性工作,明白了这一点,大家都可以经过练习写出好的方案。
第一个容易犯的错误:
只有论点,没有论证
不好的解决方案粗看起来非常厚重,其实都是功能罗列,像产品手册摘要版,不像方案书。
不好的方案是一大堆内容,淹没在一堆纸里面,也不知道想说什么,给你一个厚度,证明我们的工作质量很高。
我们国内许多的企业客户特别是大型企业都很在乎这点,认为可以从方案厚薄中看出对项目重视程度。
如果你做了精心调研,你写不出一个好方案唯一缺的是技巧。
写方案是一种技巧性工作,有个金字塔式的写做原理,也就是说文章一定是有结构的。
所以真正好的方案,不一定厚,但能看出你用心,你认真。
现在的解决方案一个不好的倾向是"长、厚、全",看起来面面俱到,其实对决策者没有帮助。
所有的方案无差异性,每家供应商都说自己能解决这些问题,而且都有成功案例。
结果所有的方案都无法给决策者简明的判断依据,不得不费更大劲去做产品演示和用户考察。
其实很少有企业高管不知道自己的毛病,在企业你随便去找一个人,对问题都能讲一通,在企业你费很大劲,可能都找不到一个人能告诉你这些问题可以怎样去解决。
通观这个方案并没有研究为什么企业会产生这么多问题?
问题是这些问题是什么产生的?
为什么出这么多问题?
而是不断说"我能!
我能!
选我,选我!
"。
如果不能找到解决这些问题的原因,简单地去解决这些现象,就象治病不能治根一样。
这样一个模板化,自我膨胀化的方案想打动用户的心是非常困难的。
不好的解决方案最大的问题就象写一篇议论文,能够发现问题,提出答案,但没有论证。
没有论证的东西不管内容陈列得多么繁复,名词多么吓人,但是无法打动用户,特别是那种理性的用户。
看到方案时候,其实很多用户下不了决心,他会感觉每家都差不多。
如果从没看过方案的人,突然看到这几个方案,你为什么会感觉某个方案写得好呢,关键是有的方案图画的好,通过图,通过表,会感觉这个公司还不错,很规范。
但对内容认可程度并不高,实际上没看懂。
第二个容易犯的错误:
业务解决方案成为功能列表
解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列,或者参照软件用户手册罗列,这种解决方案不是按照用户业务去准备的内容,而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。
大凡按照功能列表组织的解决方案用户会有一个体会,庞大而庸长,但要看到自
己想看到的部分非常困难。
而且这种方案还有一个特点,一个问题反反复复的提,在业务背景中指出某个问题,讲一通,在价值分析中又重点解释一通,到了功能介绍时又将某个问题来龙去脉概要说明一下,给用户感觉是一堆资料的堆积,哪里体现出了方案的针对性呢?
按功能列表准备方案的做法在很长一段时间内不会消失,这和普遍都是4P销售人员,还缺少SPIN销售人员有关,在资源不足的情况下,要保证效率就只能提供功能列表方案了。
本文从网络安全工程的角度探讨一份网络安全方案的编写
介绍网络安全方案设计的注意点以及网络安全方案的编写框架最后利用一个案例说明网络安全的需求以及针对需求的设计方案以及完整的实施方案.网络安全方案概念
网络安全方案可以认为是一张施工的图纸,图纸的好坏,直接影响到工程的质量.总的来说,网络安全方案涉及的内容比较多,比较广,比较专业和实际.
网络安全方案设计的注意点
对于一名从事网络安全的人来说,网络必须有一个整体,动态的安全概念.总的来说,就是要在整个项目中,有一种总体把握的能力,不能只关注自己熟悉的某一领域,而对其他领域毫不关心,甚至不理解,这样写不出一份好的安全方案.
因为写出来的方案,就是要针对用户所遇到的问题,运用产品和技术解决问题.设计人员只有对安全技术了解的很深,对产品线,了解的很深,写出来的方案才能接近用户的要求.
评价网络安全方案的质量
一份网络安全方案需要从以下8个方面来把握.
1,体现唯一性,由于安全的复杂性和特殊性,唯一性是评估安全方案最重要的一个标准.实际中,每一个特定网络都是唯一的,需要根据实际情况来处理.
2,对安全技术和安全风险有一个综合把握和理解,包括现在和将来可能出现的所有情况.
3,对用户的网络系统可能遇到的安全风险和安全威胁,结合现有的安全技术和安
篇二:
方案文书怎么写
历时一个星期的××地税数据仓库投标书从昨天开始受到了各位领导严重批评,总体来说我写的方案一无是处,只能作为陪标的一份标书。
心里很不是滋味,一周的辛苦白费不说,给领导留下的印象一定是能力极低。
思前想后,觉得各部门领导们的意见还是很有道理的,从不同的高度,用不同的方式看待一份投标文件应该具备的内容,侧重点在哪里,哪些客户最关心,哪些应该具体描述。
总结一下,死也要死个明白:
首先再说一下为了尽量改进一下我的标书,昨天上午临时添加了一份点对点应答书,书中对于投标要求中的所有问题一一进行了简单的描述,很多都是“见标书XX小节”,因为时间的关系。
在写这份点对点应答书的时候,就发现一些问题在我的投标书中没有对应的描述,或者没有很明确的回答。
所以在以后做投标书的时候,一份点对点应答书是必须的:
可以检查你的方案是否涵盖了需求书中全部的内容
可以最直观的反映出方案中你用什么技术、方法来实现这些具体的问题也许因为问题没有连贯性,所以如果在投标书中体现的话,整个标书的结
构会很散,所以单独一份点对点应答书是必要的
下面总结一下投标书应该包含的内容:
总体目标
每个项目都应该有一个明确的目标,业务上的,技术上的。
目标应该是高层次的,概括的。
一个项目的目标可以有多个,比如业务和技术的目标就是两个,技术是为业务服务的,分开写会显得比较专业。
每个目标都应该用一句话就可以说明白,要精练到只用一句话描述每一个目标。
总体规划
规划就是你打算如何实现这个项目。
在下面有一个详细的实施规划,总体规划应该是实施规划的概括,比如说计划分N步实施,每一步都要达到什么效果,实现什么目标或者子目标。
在投数据仓库的项目时,因为客户对数据仓库的认识和使用本身就是一个逐步认识、体验的过程,所以数据仓库一般会包括数据仓库基础平台的建设(数据集中、数据规范、数据质量等等)、报表、关联查询、主题、数据挖掘、决策支持这些步骤,对每一个步骤的认识、应用、和实现都可以是由简到繁的,可以把几个步骤合在一起,先进行简单的实现,然后在通过使用过程中随着认识的加深,再通过迭代的方式重新实现。
提到重新实现,就会出现两种方式:
推倒重来还是在上次的基础上更新。
这就是下面体系架构应该考虑的问题。
业务分析
怎么分析业务呢?
其实我也不知道,业务分析对我来说是木桶理论里面最短的一根。
对于现在我经常遇到的税务行业的数据仓库项目来说,每个项目都会出现大量的报表,这些报表大多都是税务征管系统(OLTP系统)中报表,一般是按照功能模块分类的。
业务分析也许应该包括两大部分:
客户的日常业务需求和用于统计分析的业务需求。
日常的业务需求在需求报告里面都可以得到,这也是客户最熟悉的。
怎么分析,那真要业务很熟练才行,瞎编可不行!
我就没编,所以领导
们都看出业务需求分析这部分我写的非常不够,没错!
我是真不知道怎
么分析。
统计分析的业务需求,现在税务行业主要是各种主题分析,指标分析。
再多说点就是怎么利用数据挖掘来挖掘和预测新的需求和行业变化。
上面都是和业务直接相关的,还有重要的一点要说明的是要明确方案建议书和投标书的区别,文档的目的不同,导致文档中要突出的重点不同。
个人感觉投标书比起方案建议书来说,目标更加明确,项目的范围界定比较清楚,所以在进行上述三点描述时侧重点不一样。
投标书应该紧紧围绕着需求书中的具体需求来写,与点对点应答书中的答案相对应;方案建议书就可以略微天马行空一些,但一定应该是熟悉业务人来行空才行!
下面应该是和技术相关的内容:
技术架构
整体架构
最近一段时间写的都是和数据仓库相关的建议书和方案,其实从数据处
理的角度来说,数据仓库技术只是处理数据的一种手段,它采用的技术和一般的业务系统(事务型业务系统)不同,所分析的数据的数据结构也和业务系统不同。
但是它应该是和业务系统并列的,对于客户来说,它们完成的是不同的业务需求。
从技术角度来看,它和其他业务系统一样,都要有一些基础的、共享的基本架构。
二层架构
三层架构(jsp+servlet或者J2EE)
安全架构
日志、审计架构
监控架构
我这次写投标书把这部分忘了,虽然以前做了N年的三层架构,也许是因为公司以前的数据仓库建议书里面没有写这部分,需求里面写了,但我看了没有引起太多的注意。
数据仓库好比是魔术大变活人里面最后变出的美女,而这些基础架构就是魔术中使用的其他道具,每个人都期望变出不同的东西来满足自己不同需求,不管是金钱、美女还是野兽。
数据仓库架构
这部分相对来说是最容易掌握的,对于喜爱技术的人来说。
在设计数据仓库架构之前,应该清楚的了解现在客户面临的实际的技术难点是什么,要解决和担心的问题是什么。
数据仓库涉及的技术问题无非就那么几种:
架构上的:
EDW还是数据集市、ODS还是非ODS、实时的、准实时的
还是不带实时帽子的
设计上的:
数据集成、数据规范、数据的处理、数据流程的定义、元
数据的管理
性能上的:
抽取的速度、抽取的数据量、数据仓库存储的数据量安全上的:
数据的质量、数据的监控
模型上的:
MOLAP、ROLAP
展现上的:
图表、仪表盘、钻取、旋转、切片
在描述这部分的时候,非常容易写的比较原理化,俗话说先礼后兵嘛,对于不很了解数据仓库的客户这部分多写一些,通俗一些,我觉得挺好。
但是如果写的是投标书的话,那么应该把如何实现说清楚,因为需求中会有清楚的要求和建议,希望做到什么程度,希望你用什么来实现,希望到达什么效果。
但是与点对点应答书相比,如果按照点对点应答书的顺序或者思路来描述的话,可能在结构上会比较松散。
我觉得还是应该按照上面的分类来描述,把如何实现放在每部分的内容中去。
图文并茂效果最佳
先在头脑里面把这些问题想清楚,在头脑中逐渐形成大致的轮廓,落实
在纸上用图的形式体现,要能从图中清楚的表达你的意思。
图可以分多个层次,highlevel的,lowlevel的,整体的,描述某一部分的。
曾经看过一遍报道,讲一个华裔的联合国IT职员,他在写系统的用户手册时,手册的第一个读者是大厦的清洁工,如果清洁工明白了,手册就算通过了。
当然联合国的清洁工也许学历也满高的呢。
图画出来了,文字围绕图来运筹,就能让读者看着明白,读着舒心。
以终为始,这句话真好。
不过说的容易,做起来要多练才行。
实施规划
实施的规划如同方案的编写,同样都是从需求入手、分析需求、整理规范、设计、开发、测试、维护,再加上如何进行项目管理,突出管理的重要性,因为其他的部分前面都描述过,只要条理清楚就行。
案例介绍
以前还真没好好想为什么写案例,如何写好案例?
这次通过写方案得出的教训是案例不是凑数的,是有目的的。
目的是告诉客户你不光有能力写好方案,还曾经做好过类似的项目。
所以案例分析除了介绍案例的业务、技术、环境、项目过程等情况,还要分析已经做过的项目和现在要做的项目的异同,也应该从业务、技术、环境、项目过程来分析。
所谓突出重点,这就是重点。
其他还可能包括:
项目预算
产品清单
技术支持和服务
再说说写方案、标书时应该注意的几点习惯和方法:
写方案、标书最大的威胁之一,就是拷贝粘贴。
拷贝粘贴的目的是为了节省时间,不是为了迷惑客户。
在拷贝粘贴前要清楚这些内容是完全符合你的要求、还是部分符合你的要求、还是帖不帖都一样、再不是就是为了迷惑客户使他不清楚你在讲什么。
有的时候是因为时间紧,或者没有太好的词语表达自己的意思,copy没有什么过错,错在不知自己在copy什么,知道了就没错了。
替换也是在修改方案时会用到的操作之一,千万不要完全替换,除非你非常有把握,否则浪费的不止是时间,还可能使你的内容变得千疮百孔,面目狰狞。
就像河间的驴肉烧饼、天津的煎饼果子一样,蓬天的方案和标书在业界是有名的优秀,要深度有深度,要厚度有厚度,希望大家集思广益,说出自己的心得体会,努力维护和发扬蓬天公司特色中的特色。
本文出自车载蓝牙
篇三:
如何写好解决方案
如何写解决方案?
本人是公司政府业务部唯一一名售前工程师,所以大量的方案策划的任务会落到我头上,这些方案里小的有几十万,大的有上千万。
如何写好方案一直是我很关注的事情。
我基本上都是在方案提交前一两天接到写方案的任务,而我自己的事情一般又比别人多一点,也不能不做,只好心里大骂一句,骂完后就打电话搞清楚别人的要求,边问就边构思整个方案的推导思路和结构提纲。
因为你不敢让你的同事知道你只能用很少的一点时间写方案,让他们担心方案的质量和进度保证,进而对自己的后续工作质量没有信心。
所以我其实也特别紧张,注意力也特别集中,大脑也高速反应,基本上几分钟电话或面谈完思路基本就有了,然后该干嘛干嘛,找一些零散的小时间把思路不断推导一下,然后到了一个比较安静和完整的时间段前才开始写,这个时候基本上要写的话都想清楚了,只需要不断敲字,敲字的时候也是注意力也特别集中,大脑也高速反应,越写思路越开,很快也就完工了。
写方案不难,知道怎么写才难。
关于写方案我只总结一点,结构化地去组织你的思想。
有结构就有思路,有思路就有方案。
另外真正写方案的人,对自己写过的方案是永远不会满意的,只有这样,每次都会进步一点点,解决方案水平质量就会随公司能力不断增长。
当然我曾经问过很多人,你到底为什么写不出好的方案呢?
基本上原因可以归为四类:
第一种是没有体系
一旦用户要求提供关于PDM的方案,很多人大脑是一片空白,完全不知道从哪里下手。
很多人说起自己的产品来,好象知道不少卖点,不过真要写出来,又觉得无从下笔。
这种情况一般是写方案者不熟悉自己产品体系造成的,知道一两个甚至更多的产品卖点不难,但难就难在成体系,知识就是成体系的点构成的,而不是一句一句离散的说法构成的。
因为我们这个行业从业人员说句不客气的话,大部分对所销售实施的管理系统并没有很深入的研究,都是半路出家,从头开始,在学习过程中熟悉,在熟悉过程中领悟。
所以一下子去驾驭一个整体方案是很痛苦的。
只有当一个人对一个产品思路有体系以后,才能够写出完整的方案,否则就是一个单元也要费尽脑汁。
所以一个人要想写好一个方案,首先要把自己产品的来龙去脉,功能模块,适应领域,典型客户实施情况有一个全面的了解,这样才能建立一个完整的知识体系,然后逐步补充竞争对手知识和一些技术性知识,不断深化自己的知识体系。
第二种是没有思路
有很多用户看多了模板化的方案以后,想看一些针对他们自己的业务的个性化内容,这个时候有的人按照标准方案模板修改还勉强能对付,但对于个性化内容针对性方案就速手无策了。
这种情况从根本上讲还是写方案者不熟悉企业业务造成的,写方案,特别是针对性方案不仅仅要求了解企业的需求,而且要知道这些需求是在何种业务需求下
产生的,用户提出这样的要求到底想解决什么问题,把这个问题找出来,一般针对性解决思路就有了,有了思路,自然可以很好的写方案。
所以一个人要写好方案,还需要了解下游客户的业务,了解业务最有效的方法就是亲自做几次详尽的业务调研,有了业务调研做基础,在调研过程中把握用户关注重难点问题,自然可以比较好的确定方案的个性化内容思路。
解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。
第三种是没有素材
一般不经常写方案的人,在写一个方案的时候,即使有想法,有思路,但往往也会很累,就是因为缺少足够的素材。
很多项目现在都是投标,不同用户可能有不同投标的要求,这样很难用一个方案去适应所有的用户,因此在每个方案中都有一些需要准备的内容。
这些内容基本上是通用的,但如果没有足够积累每次编制方案就需要花费大量时间去准备,造成方案完成周期过长。
所以写好方案必须具备这三个条件,第一方案编制者对企业业务要很熟悉,或者有相关业务调研经验,第二方案编制者对产品非常熟悉,至少对自己产品功能模块作用很清楚,第三方案编制者手上有大量可公用的素材库。
第四种是没有层次
很多人刚和用户接触没有多久,为了表现自己对客户的重视,马上表示要提供方案,当然有的客户刚刚开始选型,也不知道到底要什么搞,也要供应商马上提供一个方案。
结果拍胸脯容易,写方案难,自己写不出来只好求公司,公司没有安排专人了解情况,只好按模板制作一个,用户一看几个供应商内容都差不多,觉得不好,又总结出一些个性化要求,于是大家有开始折腾第二轮方案。
其实方案编制在不同阶段有不同策略,不要轻易提供方案。
刚开始接触是可以提供项目合作建议书,类似可行性报告,项目需要考察软件技术,可以提供标准的产品技术白皮书,到了经过售前调研,有所准备,在演示前后阶段和其它竞争对手刺刀见红的时候,才在知己知彼的基础上提供解决方案或者投标书。
过早提供方案只能匆匆了事,时间紧急,质量自然不高,自然也就觉得方案难写。
想急就又能解决问题的事情,本来就是一般人做不来的。
方案想要写得好,一定要用心,用心就一定要耗时间,指望用几个小时写出一个高质量的方案是不可能的。
如果你做了精心调研,你写不出一个好方案唯一缺的是技巧。
写方案是一种技巧性工作,明白了这一点,大家都可以经过练习写出好的方案。
第一个容易犯的错误:
只有论点,没有论证
不好的解决方案粗看起来非常厚重,其实都是功能罗列,象产品手册摘要版,不象方案书。
不好的方案是一大堆内容,淹没在一堆纸里面,也不知道想说什么,给你一个厚度,证明我们的工作质量很高。
我们国内许多的企业客户特别是大型企业都很在乎这点,认为可以从方案厚薄中看出对项目重视程度。
如果你做了精心调研,你写不出一个好方案唯一缺的是技巧。
写方案是一种技巧性工作,有个金字塔式的写做原理,也就是说文章一定是有结构的。
所以真正好的方案,不一定厚,但能看出你用心,你认真。
现在的解决方案一个不好的倾向是"长、厚、全",看起来面面俱到,其实对决策者没有帮助。
所有的方案无差异性,每家供应商都说自己能解决这些问题,而且都有成功案例。
结果所有的方案都无法给决策者简明的判断依据
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 解决方案 编写 基本思路